Friday, 4 August 2017

Why you need WIP limits

Why is this crazy person telling me to limit my WIP?

As an agile coach I often come across situations where I need to encourage teams to reduce the amount of work they have in progress. Even though it sounds and feels counter intuitive to do less work, the fact is your team will get more DONE by doing fewer things at the same time.

Activity != Progress


In our scrum teams we naturally tend towards keeping everybody busy. Developers working on development tasks, testers working on testing tasks. History has skewed our mental model of what people should do at work so that we feel like we should always be busy, always processing work. 

This is a good model for the mass production of widgets or the processing of mountains of paperwork BUT a bad model for the production of complex, functional, high quality software.

We use user stories to represent units of complex, functional, high quality software and in scrum the game is to finish a number of these units every sprint. This goal is often overlooked in favour of keeping team members busy. As long as everyone is busy we will eventually deliver the user stories. This is possibly true but they will be delivered in an inefficient and unpredictable manner.

You are slowing your team down by not limiting WIP


What do you mean, how can I slow my team down by working harder on more stuff?

Well you are the guy who is so good at building car doors, that you have focused yourself solely on the optimization of your work for the creation of car doors. This results in the creation of many, many car doors BUT doesn’t deliver any completed CARS from the production line and now if you look around, the factory is full of the car doors and the stockpile is slowing your work colleagues down. They are tripping over doors and themselves. You are increasingly spending your time managing piles of doors, stacking them, shipping excess doors to storage, retrieving them when they are needed and we as a team are still not shipping any finished cars.



My previous blog post on this topic described how we favour working on our areas of specialty (dev & test) and how this results in teams starting more work in order to serve our specialisms.
This works well to keep individuals more productive (or at least occupied for more time) but it doesn’t work well for helping a team to deliver its user stories to DONE.

Instead of continuously creating car doors (pulling new user stories in order to perform new development tasks). What if the car door guy builds a limited number of doors? Just enough to keep the team going for a while. Then instead of building more doors, he stops. He is now “idle”. We don’t like “idle” time, we’ve been trained historically to fear “idle” time. However idle time (or slack time) is crucial if we want to ship any finished products.

How can we go faster when people are idle?

This goes against all your instincts. Team members should be busy. Developers should be developing. You need to change your instinct to read “Teams should be delivering finished work”.
Optimize your ways of working for teams finishing user stories, not for individuals finishing tasks
When car door guy creates just enough car doors to keep the team moving then stops creating car doors he doesn’t sit around being idle. He is a good worker, he wants to do good work and he wants his team to be successful.

His first instinct is to tidy his work-area. This means he will be faster and more productive when he next comes to build more car doors. His previous inventory of car doors is no longer cluttering up the production line. His colleagues are free to do their work more productively. We don’t need to transport car doors to/ from the store room. We have saved ourselves a lot of time and hassle purely by ensuring car door guy is doing less car door building. This is not to say we don’t value his work. We need car doors, we can’t build cars without them but once we have sufficient car doors to keep us going we have other work to focus on as a team.

Once the car door production area is spick and span, car door guy looks around for something else to do. He is really good at making car doors, but the team has blocked him from creating more than is needed. What should he do? He wanders over to his colleague further up the production line and asks if he can help in any way. He doesn’t feel like he can help much given that his skillset is only in the making of car doors. The team encourage him to work with a colleague and learn how to attach his car doors to car bodies. Car door guy expands his skillset and we are one step closer to having finished cars

By limiting WIP team members will frequently be blocked from starting new user stories simply to serve their specialisms. This is a really good thing. It will result in a number of new and wonderful behaviours.

  • Team focuses more on the completion of finished products/ user stories (not just dev/ test tasks)
  • Individuals stretching their boundaries and learning new skills. (developers helping with testing, test automation, learning new programming skills/ languages outside of their main specialism)
  • Less waste and unfinished work in the system, means we can ship finished work faster
  • More refactoring and automation

Stop starting – start finishing


Once you’ve finished your stories you can play some more. Don’t pull in new stories before you finish your current in-progress stories and don’t pull in new stories if you still haven’t met your sprint commitment. Finish  the things you start before you start more things, it makes sense right?

Monday, 24 July 2017

The "right" way to do stand ups

In my last post about daily stand up meetings dated(2011!!) I mentioned the standard format these typically take:

  • What did you do yesterday?
  • What do you plan to do today?
  • Do you have any blockers or impediments
We are all familiar with the approach. However, I often see teams losing focus of their progression against sprint goals due to executing the stand up poorly. 

If you find that going "round table" for individual updates is not providing any clarity on the progress of stories then it might be time for a change. Take this example:
  • Yesterday, I had some meetings. I caught up with my emails and i had a dentist appointment in the afternoon
  • Today I will catch up with Jane & Mike about Project Dilbert
  • No blockers
The format is correct BUT the content was of little or no value. Why? Because the update was not pertaining to any of the user stories in the sprint and the progress being made towards its completion.

My previous post states that we should "focus on progress". A scrum master should look at the above update and ask the team member:
  • What user story are you working on? 
  • How is that story progressing? Are you making headway? Do you need any help from another team member?
If the team has a kanban board then it should be obvious what story everyone is working on and the team member should provide a brief update about the story progress, not what they had for breakfast this morning, it's just not relevant.

The BoardWalk

The approach to stand ups that solves this problem is the "BoardWalk". The team goes through all the cards on the board (or at least the relevant ones, usually the ones in progress). Typically we go from right to left (focusing on stories that are closest to completion first) and we ask for a progress update on each story. 

This approach ensures that we focus as a team on the progress of the stories we have in the sprint. The updates the team members provide for each user story can still take the format
  • What did you do yesterday? (on this user story)
  • What do you plan to do today? (on this user story)
  • Do you have any blockers or impediments (on this user story)

But using  the Boardwalk all team members may not get a chance to share their update?

.... and that's OK!! 

If multiple people were working on a story and one can provide a relevant update as to how its progressing then that's OK, we don't HAVE to hear an update from everyone.

You can switch between stand up formats



As with everything we have passionate advocates for either of these formats over the other.

  • "Focus on the board walk its the only thing that matters"
  • "Go round table - we need to hear from everyone"

Both approaches are valid, until they're not.

  • Focus on the board is great for progress visibility but might eventually result in team member alienation.
  • Focus on the team members is great until we realise we are constantly missing our sprint commitments due to lack of progress visibility on a daily basis.

So here's the trick, listen closely... you can switch between these two methods. You could even try some alternative approaches if you're feeling experimental.You don't have to stick to the same format for ever and ever AMEN! It's good to change things up.

  • Try the standard way, if you feel updates are getting stale and uninformative then agree with the team to try the boardwalk.
  • If the boardwalk yields results but you feel like you don't hear from certain team members enough/ often then agree with the team to toggle back to the standard format

The extra benefit of switching back to the standard format from the boardwalk method is that you will find team members updates will now be more focused around story progress than they were before, due to the practice they have had when using the boardwalk method.


Friday, 1 May 2015

Agile is a team game

Agile software development is a team sport. I see so many issues when working with software teams that I have also come across in a sports team context. Teams are collections of people and to get a collection of individuals motivated and organised to achieve a common goal is not easy. I am convinced there is much we can learn from  the sporting arena to help us perform better as software teams. One example is the concept of Individual efficiency vs group efficiency.

Individual v team efficiency

A lot of what is important for the success of sports teams is also valuable for software teams. We create teams with a view to the Team achieving more together than the individuals would on their own or because the task/ deadline before us is unachievable without extra man power. 

Example: Amazing footballers like Lionel Messi, Cristiano Ronaldo, Diego Maradona could not  achieve anything on their own, they need to operate within a team structure to achieve any great success


Often organisations are trying to deliver projects to crazy deadlines which mean they need the extra manpower a team structure can provide. They cannot rely on the superstar, the Ronaldo, to do it on their own. For star players and gifted individuals, sometimes this means sacrifice. A sacrifice to how they would normally do things. A compromise of their individual efficiency for the sake of the team efficiency.

An example of this that we might be familiar with in software teams, might be where a team debates whether to break a large user story into multiple small stories. The star developer feels he can be individually more efficient by tackling the big story on his own in one go. However by breaking the work into smaller chunks the team gains a lot: ability to show incremental delivery, ability to spread the knowledge throughout the team, pride that the whole team can contribute rather than just one superstar, future reduction of key man dependency, shared knowledge of the system, early identification of risk/ complexity.

Often, using agile means sacrifice for the expert individual but it results in a stronger team, the herd is only as fast as its slowest member, not its fastest. This can cause conflict in some cases with the star player finding it difficult to sacrifice or to spend time coaching others to an enhanced level. The bottom line though, is that organisations need to have multiple, reliable delivery teams rather than a handful of exceptional individuals. 

Important! This doesn't mean we don't want to have exceptional individuals in our companies or teams but ideally these should compliment outstanding delivery teams, not prop up poorly functioning teams :)

Thursday, 10 July 2014

Slice the peach

 When should you split a user story? Think "when would you slice a fruit?"

  • A banana is big but manageable you'll probably eat it whole. You might want to slice it in certain circumstances.
  • A peach could get messy so i'd rather slice it
  • A kiwi is small but its hairy, i'm definitely slicing that!
Deciding when to slice a user story is not always easy. Often its difficult to apply hard rules. Its usually a balance of size and complexity.

In the above examples, a banana represents a big story that isn't complex, should size alone determine whether to split it? The kiwi represents a story that is small but highly complex, we know its hairy, we know we shouldn't bite straight into it but how to slice it is not obvious either? peel first? slice first?


The peach represents the story I see most often. It represents uncertainty. Once you bite into a peach you discover if it is hard, soft, juicy, extremely juicy! If you slice it up first then you know exactly what you're getting and its much more manageable if things do get messy



Monday, 19 May 2014

Moving beyond tasks

One of the most common agile anti-patterns I witness is a compulsion towards breaking user stories into tasks.

Tasks take focus away from stories

The problem with tasks is that they take the focus away from user stories. Teams that focus on completing tasks risk losing sight of the real value which lies in the stories. They are often unable to see the wood for the trees.

How often have you seen sprints that are?
•             On day 9 of 10, but <30% of story points are complete
•             On day 5 of 10, but <10% of story points are complete
•             On day 9 of 10, with 90% of tasks complete, but still <30% of story points complete

I firmly believe this is a by-product of too much focus on tasks and not enough focus on stories.
Tasks themselves add little or no value on their own. I often see tasks such as “Manual QA”, “Code Review”, “Write test cases”, “Database work”, “Front end work”, “Back end work”. People often argue to me that the task breakdown ensures they don’t forget to do certain parts of a story. If we need a task to remember to do code reviews and testing then we are in big trouble J.  Also a simple check-list will suffice, that doesn't have any rally/ jira overhead.

Tasks are unlikely to help you to limit your work in progress

Let’s say a sprint starts with 10 user stories. Each story breaks down into 5 tasks giving us 50 tasks to get through.  Let’s suppose a breakdown of 20 front end tasks, 10 middle tier, 10 back end & 10 test and a team consisting of 1 FE, 1 Java, 1 DB and 1 QA.
Day 1 of sprint everyone is eager and wants to start a fresh, new piece of work. Everyone will naturally choose a task that fits their specialism. If we are lucky there will be some alignment so that we at least have multiple people working on the same user story. As people start finishing their tasks, they will, again, naturally choose the next task from their specialist area. They bring a new story into play, thus increasing the amount of work in progress. Nobody ever picks from outside their specialism which ultimately leads to a large portion of stories in play at any given time. This gives us the situation where lots of stories are starting but not many are finishing. Not to mention a massive tendency towards specialism where each person stays rigidly within their own skill set.

Why do we want to limit WIP?

CFD charts that look like this highlight a large amount of WIP. 















Halfway through the sprint there is very little work complete. This is a big risk that the sprint is going to fail. Or at the very least it doesn’t inspire confidence that the investment in the sprint is going to deliver.

CFD charts like this one provide more confidence that work is being delivered incrementally & early and the risk of failure is reduced. Its no coincidence that this team has limited work in progress throughout the sprint (the yellow section)















The more WIP, the more EXTRA UNNECESSARY work we generate for ourselves. There’s additional overhead of merging, managing the separate stories and tasks, discussions between developers and QAs about ALL the stories in play, discussions about integration of all the stories in play etc. It’s much more difficult to integrate with moving targets. Every new story you bring into play results in a delay in getting currently 'in progress' user stories into DONE!!

Finally, and quite simply... Managing tasks is waste! They introduce an unnecessary management overhead. Each task needs to be managed in rally/jira. Undoubtedly, precise estimates will be required (in hours) for how long each task will take. Time spent on a task versus the estimate will no doubt be tracked. All of this is time spent NOT adding value for the customer.

Limited WIP helps you delivery incrementally

Incremental and early delivery of your sprint user stories gives the following benefits:
  • Reduced cycle time (due to less unnecessary work mentioned above)
  • Reduced risk (earlier delivery)
  • Fast feedback (early integration/ early visibility of deliverables)
These are some of the main gains we should get with an agile development methodology. Otherwise we are doing big batches of work that inherently hold risk, and are delaying visibility of deliverables.

Tuesday, 21 May 2013

A short story about fish



About 6 months ago my team embarked on an initiative to upgrade our Continuous Integration (CI) & Automation pipeline. As an iOS team, the fact we already had a comprehensive suite of automated functional tests hooked up to Jenkins was impressive and gave us a solid foundation. However, our setup had started to creak at the seams. Inexplicable test failures, brittle tests, failing tests that miraculously worked if we gave them a swift kick in the nether regions and ran them again! We decided to evolve to a CI 2.0, which would be a lot more stable, massively reduce the amount of time we spent nursing our tests and ultimately give us better confidence in our system. We are not done yet but we have re-learned a number of basics along the way

Lesson 1: with CI & automation, fast feedback is king
Our monolithic test suites took hours to run. This discouraged developers from running them on every check-in, which is counter productive. Not running them means you increase the chances of breaking functionality or introducing defects with each commit.

To achieve faster feedback we have split our tests into smaller test suites each with its own Jenkins job which means we now start to get feedback in tens of minutes rather than hours.

Next steps :
We want to set up a grid system, to run the tests in parallel to further reduce the time to run

Lesson 2: Responsibility

When you don't have fast feedback You also get in a situation where breakages can't be easily traced back to a single code commit, as the 'window of culpability  is open for a few hours/ half a day. Anyone who commits in that period could be at fault. Who does the investigation to see what caused the breakage? Without trace-ability  it's often a case of thinking 'someone else will look into the failing tests' which means, probably, no one will look into it!

We introduced the concept of a 'Weatherman'. Someone who is responsible for investigating any breakages and getting them fixed as priority. This role is rotated on a daily basis so it doesn't become too much of a chore for any one individual.

This brought more visibility of breakages and helped change the culture of the team to have quality and visibility of quality as a priority on a daily basis.

Lesson 3: Granular feedback

I mentioned already that we broke our tests into smaller suites. Great for fast feedback, but also granular feedback which helps when trying to pinpoint the breakages. Also, if you have one failing suite you still have confidence in all the other passing suites. With the monolithic test suite we didn't have that confidence.

Lesson 4 : Keep your tools sharp & get new ones when you have to

We were using Apple's UI automation tool, but it started to show signs of flakiness and incompatibility with what we wanted to do. You would expect apple to produce a solid tool but further investigation showed that they don't really invest too much in UI automation which meant we had to start considering other tools.

We have now started to use FRANK for automated acceptance testing, which has led us down a behaviour driven development (bdd) path. (Bonus!)

Lesson 5: Appreciate legacy code

Appreciate when your legacy code is giving you value and not costing you much - you don't always have to migrate everything.

We continue to run our stable legacy tests in parallel with our shiny new frank automation tests. They are stable and don't cost us much time in maintenance and still give us good value. It would take months to fully migrate them so we won't bother unless we have a compelling case for making that investment.

Lesson 6: Adopt a culture of quality

As mentioned previously, the concept of a weatherman, who gives the team it's daily weather report, has massively helped change the culture of the team. Quality is everyone's responsibility but on a daily basis it's even more so the weatherman's responsibility!

Having experienced the pain of brittle tests packs, slow feedback, poor tools etc the team now knows the value of staying on top of our CI and automation packs and ensuring we have the speed and feedback that we need. .

Conclusion 

That's our story, we are more than halfway to having a slick CI pipeline. The improvement we have made is fantastic bearing in mind that all this was done on top of regular sprint work and deliveries. Great commitment from the team to improve the culture, environment and toolset.
Previously we were getting some of the value of CI & automation with a considerable maintenance cost. Now we are getting a lot more benefit with a lot less maintenance. Happy days.

Finally, To make sure nobody leaves disappointed ..... Here is a picture of some lovely fish!


Tuesday, 23 October 2012

What a makes a GREAT scrum master?




Part time scrum master?

Many software teams who claim to be "doing scrum" have people “stepping into” the role of scrum master.
I frequently see project managers, development managers, testers, developers taking the reins with varying degrees of success. Often, willing team members take on the role of scrum master in addition to their development or testing responsibilities! I also see a lot of teams going solo, i.e. doing scrum without a scrum master. This is a practice that I think ultimately prevents a team from improving and getting full benefit from the scrum process. Even if someone possesses all of the soft skills to the do the role, they still need to have the core skills and knowledge required to be an effective scrum master.

The scrum master responsibilities

  • Be the Guardian of the scrum process
  • Be a servant-leader to the team
  • Be an impediment remover
  • Be an interference shield for the team
  • Be a coach
  • Be an agent of change
I don't think that a part-time or temporary scrum master can fulfill all of these responsibilities and to do this role successfully you need to be all of the above things to the team. I think that someone who steps into the role can be a good scrum master, but will they be a great scrum master?

Two levels of scrum mastering?

I think there are 2 levels of scrum mastery.

Level 1: B.A.U.

This is the layer of scrum mastering that keeps a team ticking over. The part-time or temporary scrum master tends to operate at this level. The list of responsibilities include (but are not limited to):
  • Be the Guardian of the scrum process
    • Ensure PO has a backlog of stories for the team to work on
    • Ensure PO has prioritized a list of stories before planning
    • Ensure the team is clear about the requirements
    • Encourage the team to make a projection of the amount of work they can achieve in the sprint
    • Ensure team feels comfortable with projection versus current velocity
    • Protect the sprint backlog
    • Limit W.I.P.
    • Ensure the team focuses on quality
    • Monitor the stand up (make sure people don't waste time, keep updates short, stay on topic)
  • Be a servant-leader to the team
    • Set up all scrum ceremonies
    • Point of contact for Scrum updates.
    • Send out reports/ burn-up charts
  • Be an impediment remover
    • Remove barriers to productivity
    • Help to resolve issues/ arguments/ debate
  • Be an interference shield for the team
    • Maximize time available for developers to develop (protect dev time )
    • Reduce waste/ non sprint activity
    • Protect team members from being dragged away to work on non-sprint activities
    • Protect the team health and well being

Level 2: Strategic

This is where all the good stuff happens. A full time, "proper" scrum master will operate at this level.
  • Be a coach
    • Help team to self organize
    • Help the team to improve engineering practices so that each sprint/ story is potentially deploy-able
    • Help the team understand Scrum/ agile principles and techniques (rather than just mindlessly following a process)
    • Help the team understand the benefits of these techniques
    • Help the product owner manage the backlog
    • Remove the distance between the PO and the team
    • Teach the PO how to maximize R.O.I. and meet objectives through SCRUM
    • Ensure the team is learning in retrospectives
    • Promote continuous improvement
    • Coach a team to self sufficiency (e.g. how to remove own impediments)
  • Be an agent of change
    • Observe & identify areas for the team to improve
    • Create a culture of continuous improvement in the team
    • Facilitate creativity and empowerment
    • Determine where the Scrum process is compared to where it could be
    • Potentially look beyond scrum, for techniques that can help the team improve (e.g. Lean/ kanban)
    • Challenge the team to improve engineering practices (CI, TDD for example)
    • Look to improve things outside of the team that are slowing the team down (e.g. business stakeholder involvement, handover to dev ops, poor communication across the organisation)
    • Keep an eye on the future 

High performing teams through great scrum mastering

The scrum master who operates at the strategic level will give teams a massive boost over time. To have someone who is focused on improving a team and making a team awesome and improving a team's working environment means that inevitably, positive change will occur within a team. The alternative is stagnation. 

If your team has a level 1 scrum master or worse, no scrum master at all, who is going to constantly beat the drum for improvement? who will keep an eye on the future and the health of your scrum process? Who will promote constant improvement? Who will ensure the team is always learning?

In my experience, having a great scrum master with a strategic remit, facilitates the growth and nurturing of awesome, productive, high-performing teams. This stuff doesn't just happen!