Taking back the Daily Scrum


This is what you might know as the daily ‘stand up.’  It is the most abused, tortured and mistreated meeting in Scrum.  Or not even Scrum.  If nothing else, this is usually the part of Scrum that organizations adopt and keep.  If they do nothing else then they do this.  And boy do they do it!  This meeting is too good for 15mins, let’s keep it going for 45!  There are some common anti-patterns that I have come across during this meeting so I thought that I would share them with you.

The WaterBoarder

Torture.  Plain and Simple.  I am going to keep you standing up for 45 minutes whilst everyone tells me what exactly they did yesterday and what they plan to do tomorrow.  Have a problem with the binary search function?   Lets discuss it whilst we all stand here listening.  Hey the 10 of us have nothing better to do.

The 8 Teams of 1 Person

We are not a team.  We work on our own.  We talk once a day at this ‘mandated’ meeting.  Then we each go our separate ways until tomorrow.  We work on one task / story each.  So we give our update.  Then we have to listen to 7 others give theirs.  But we don’t care.  It does not affect us in any way other than having to stand through this boring meeting.

The Wall Talker

He approaches the board.  He stops.  He looks around and starts talking.  Quietly.  No-one can hear him because he is talking to a wall.  Everyone strains to hear, and then gives up.

The Over Sharer

I know that I didn’t finish much yesterday but let me explain why.  Well I had an unscheduled meeting from 10 until 11.  I then got a call from my mother in law who said that she had a sore knee.  I had to leave work early to drive her to the hospital and then take her home…..

The Goldfish Memory

I can’t remember what I did yesterday.

The Photographic Memory

Arrives with pages of notes to read from to justify quite how busy they really are.

I am fine with status meetings.  If you want to have a status meeting go ahead.  But call it a status meeting, give me a chair and bring lunch.
Now for the really controversial part.  Who said that you have to stand up?  Really?  Let’s just check the Scrum Guide on that again shall we…
Want to sit down at your Daily Scrum, do it.  If any of these meetings sound like yours then maybe it’s time for a change.  We stood up because the meetings were short.  If the meeting isn’t short why are you standing up?

Photo licensed via Creative Commons


Agile Leadership


Management Thoughts from San Francisco

Another course delivered.  As always waiting for a plane.  This time I am thinking a lot about management in an agile organization.  The agile community has had much to say about developers, testers, BA’s etc.  But very little about managers.

Some would say that managers are not needed anymore.  They are dinosaurs – on the verge of extinction and Darwin will have his way.  I am not one of them.  I see no end to our need for managers.  Just a different role for them to play.

There is a lot of talk about the Spotify agile scaling approach.  People talk about squads, guilds and chapters and the lack of hierarchy.  Hold on.  If you examine the Spotify approach you will see that the Chapter Leads are Line Managers. 

And what of culture.  Who sets the culture of an organization?  It comes from the managers.  Traditionally in agile transformations the developers, testers, scrum masters etc get a lot of attention and training.  The managers are almost universally ignored.  They only get told about things that they do not need to do anymore. 

They don’t need to assign tasks.  They don’t need to check on status.  So what should they do with all of this extra time?  Approve holidays?  Timesheets?

I am often asked what is the role of a manager now that my teams are all self-organizing?  How do I add value to my staff without getting in their way?  How can I perform performance reviews?  Salary adjustments? 

I have been following Jurgen Appelo’s Management 3.0 work with interest and I like what I see.  A lot of the thinking has much in common with the Kanban community.  It speaks to an actual management role within an agile organization, and frames the role of a manager as a pivotal position that can add enormous benefit to an organization if done well.

How can I create high performing teams and tap into my team members intrinsic motivations?  How much do I delegate to a self-organizing team?  How do I help to create an 'agile culture'?  What opportunities does an agile transformation provide for managers?  What new skills do I need to help my teams be successful?  These are real questions that need answers.

If you are part of an organization undergoing a transformation do not ignore your managers.  They are key to your success.  If you are a manager in an organization undergoing a transformation - do not be ignored.  Demand more.  Demand answers to these questions.  We still need you, and your company and teams need you.


Product Owner as Superhero



I am sitting in in a café in Singapore enjoying a well-deserved drink and dinner after teaching day 1 of the Scrum.org Professional Scrum Product Owner course.

We have students from Indonesia, Singapore and Cambodia on the course.  We have spent much of the first day chasing the idea of value in product development.  Where does the value reside in our product backlog.  How do we identify it, prioritise it and maximise it.  Identifying value is hard.  Is it our value, our customers value or both?  Is it profit generated, satisfaction earned or costs saved?  These are some of the many challenges of Product Ownership today.

We ask a lot of our Product Owners.  We ask that they be entrepreneurs, experimenters, and like product explorers.  We ask that they provide a clear compelling vision to our teams and are able to accurately represent many conflicting stakeholders.

This is hard.  Are we asking too much?  Can you really bring a start up mind set to a bank or an insurance company?  Can a validated learning approach really exist in corporate IT?  Are they able to actually interpret and respond to Scrum’s feedback loops?

Many companies ‘assign’ product owners from the ‘business’ (don’t you love that word.)  If you talk about anyone outside of IT as ‘the business’ then I worry for you.  If you see them the business, what do they see you as?  Probably a monopoly provider of questionable service.  What do you think would happen if ‘the business’ could choose a different service provider?  Would they still choose you?  If they didn’t could you attract new clients?  I thought not.  You care about the success of the organisation.  So do they.  You are on the same team.  You are not ‘trusted partners of the business’, you are the business.

An assigned Product Owner who already has a full time job will not work – yes I did say that.  Let’s turn this round.  Are you a full time developer / tester / ba / other – great.  Let’s pretend we have an exciting new project and it’s so important that it gets funded.  We show how important it is by having you be the Product Owner.  As well as your day job of course.  What could possibly go wrong?  These are often multi-million dollar programs / projects.  I don’t want to devalue your day job, but really?

We ask a lot of our Product Owners.  Maybe too much.  But don’t make it impossible.



Don't worship at the altar of Scrum

I am a Scrum Trainer with Scrum.org.  I work with lots of organizations to help them become more agile.  I see a lot of bad Scrum.  More than my fair share.  Sometimes I see so much bad Scrum that it makes me question why I do this.  This post is my attempt to remind myself why. 

What is bad Scrum?  Lets start with what it is not.  Scrum is not about following rules.  There is an industry full of people that have turned Scrum into a religion.  I kid you not.  They even have names for themselves.  They call themselves 'white robes'.  They obsess over every change to the Scrum guide and translate the 'founders' intent for you.  They will speak of your dysfunctions (sins), they will point out your deviations from the one true path and they will shame you.  Scrum is not my religion.  Don't make it yours.  Be skeptical.  There are no higher beings when it comes to Scrum.  I am not a high priest and I don't need a high priest.

Scrum is not about mechanics.  They are merely there to serve a purpose.  The mechanics are a means not an end.  The mechanics do not define the result.  Can I follow all the rules and mechanics and have bad Scrum - you bet.

Scrum is freedom.  Freedom from the tyranny of trying to meet someone else's commitments (made for you.). It is freedom from being told to be 'accountable', meet your 'commitments' and other 'motivational' words.  It is freedom from being measured against someone else promises.  It is freedom from feeling like a cog in an endless machine.  It is freedom to question, to discover, to disagree, to decide how to work, how to improve and how to make your own promises.

What is bad Scrum?  If you are not feeling any of these freedoms and you are 'doing' Scrum then you already know the answer.  Bad Scrum is mechanical.  It's a belief in magic.  If we stand up for 15mins every day, attend lots of meetings, call someone a Scrum Master then things should be better right?  A Scrum Master just books the meetings and makes sure everyone turns up right?  Right?

If we decide the features that should be in a release and we decide what date that release will ship we can just tell our self-organizing team and they should be able to deliver it, right?  Welcome to bad Scrum.  If we decide that the Project Managers should be Scrum Masters but our new teams are self-organizing and therefore accountable for the outcomes, welcome to bad Scrum.  If you are being asked to 'drive success' for the team then you are not part of the solution.

Lots of companies decide that Scrum has too many holes.  It doesn't dictate documentation, dependencies, scaling etc.  We need to define that.  So they reach out to a prescriptive model (SAFe - I am looking at you) or 'customize' it to add what is missing.  Welcome to bad Scrum.

The gaps ARE the power.  The gaps are where we can decide what works best for us.  The gaps are the opportunities.  Revel in the gaps.  Glory in the gaps.  The gaps are what makes this what it is.  The gaps are where teams can actually define their own future.  The gaps leave room for a self-organizing team to exist.  Scrum doesn't need to be customized - just fill in the gaps with what makes your team special.

There is genius in empiricism.  Predicting the future is hard.  Adjusting to evidence is easy if we are given the chance, and people are willing to hear the truth.  A team that is allowed to self-organize don't need anyone to 'drive' them.

Good Scrum is not about measuring adherence to practices or mechanics.  Be skeptical.  If your consultant arrives and defines success by measuring practices, think about what you are advocating.  You have created a proxy for success.  That proxy involves post-it notes and standing up.  Really?

Good Scrum is exciting.  Good Scrum teams have purpose.  They have fun.  They are not defined by the length of their planning meeting.  Good Scrum teams do not need someone to 'empower' them.  I have my own power thanks and I don't need yours.

Good Scrum teams crave feedback.  They crave it from their process, their products, their stakeholders, and each other.  Feedback is power.  Feedback drives improvement.  The Scrum framework gives us a way to gather feedback.  Our response to this feedback defines us.

These teams need someone to care.  Someone to care about more than just the next feature, or project deadline.  Scrum Master this is you.  You are there to create the environment for this type of team to exist and thrive.  You are there to gather this feedback, and help your organization act on it.  Do nothing and expect no improvement.  Scrum is merely the vehicle that will surface these opportunities for greatness.  They will be challenging, they will appear unsolvable.  They are not.  Look at each day and ask yourself - 'are we better than yesterday?'

Your job has nothing to do with booking meetings.

If you care - I hope we meet.

What type of Scrum do you have?


Modern Product Ownership

One of the most critical roles in Scrum is the Product Owner.  When I consult with organisations about Scrum, often they want me to focus on helping the person in this role.

Some PO's are full time, however most PO's I meet are part-time.  They already have a job.  They are unsure how much time this additional role will take.  They know their business but they often do not know Scrum.

More importantly they often do not understand how short iteration development should work.  Lots of the books and blogs say glib comments like 'The PO should manage the product backlog in order to maximize the ROI of the product

Sounds great, but how?  Is putting the Product Backlog in order enough?  No.

Good Product Ownership means an understanding of Scrum, why it works, and a number of complimentary techniques.  For example what techniques should I use for prioritisation? 

  • Moscow
  • Kano
  • Business Value
  • Risk
  • Walking Skeleton
  • Validated Learning
 How much should I spend writing User Stories? (hint: probably not much)

Release Planning is worth a separate blog post entirely but this is another key area for a PO to understand and spend time planning.  Many PO's like to use a story mapping approach to build a product backlog and create a release plan.  Story Mapping is an essential technique that all PO's should understand.

The Lean Start up movement is also a rich source of ideas that are finding their way into a modern PO's toolbox.

So next time someone asks you to be a PO.  Ask yourself - do I understand how to use these techniques to extract the maximum value from my Scrum team?

Would you like to understand the principles of modern Product Ownership?  Are you struggling with how to get the most value from your Scrum team?  We have Professional Scrum Product Owner training that can help.  See our current list of public courses here http://www.robmaherconsulting.co.nz/Classes/PSPO or ask for private training at http://www.robmaherconsulting.co.nz/CourseRequest

Developer Tools Webinar launched!


Microsoft NZ has started a monthly Developer Tools webinar.  Featuring yours truly we talk about what’s new in Visual Studio, ALM and all things Dev Tools.  You can check out the first edition here - http://blogs.msdn.com/b/joenewton/archive/2013/10/01/nz-developer-tools-webinars.aspx


The first episode focuses on a Tech-Ed wrap-up, MTM 101, and a demo of the awesome new BrowserLink feature.


Coming up in October is Visual Studio 2013, and in November we will be focussing on the Visual Studio launch.  Feedback would be appreciated, and if you have any topics that you think would like to see included please get in touch!


Featured on the Microsoft .NET Developer site


I was interviewed by Microsoft as part of their Developer Stories section on the Microsoft.com site.


They selected developers using .NET technologies and wanted to get background information about their views and background history. 



Rob Maher

Not many developers have Rob Maher’s geographic diversity. Born in Great Britain, he’s worked everywhere from the Philippines and Singapore to Saudi Arabia and the United States. A self-described “serial conference organizer,” he also regularly oversees Scrum, Kanban and Microsoft-related events in his adopted country of New Zealand.

“Fortunately, my wife and four-year-old son like traveling too,” he says.


See the full interview here:-