If I were a painter, I…

Recently I have spent a lot of time talking about story writing, but this week the focus has been on Acceptance Criteria and there have been a variety of comments that have caused me to reflect and have caused me some concern.
Some examples:

  • Unless stated otherwise a story is assumed to be happy path only. If it isn’t in the Acceptance Criteria we don’t have to do it.
    • Acceptance Criteria must contain all details including all edge cases that must be tested, anything not stated doesn’t have to be implemented.
  • If all acceptance criteria are met the PO/Customer MUST accept the story even if they are not satisfied.
  • If acceptance criteria change before the story is done, it should be completed as specified and a new story should be created for the changes. after all, late changes to Acceptance Criteria demoralize Developers.
  • If Acceptance Criteria are unclear we can choose what to do.
  • The Acceptance Criteria should never tell us how to do the job.

A metaphor

To respond to these questions I thought I would use a metaphor – A homeowner wanting to redecorate her house.

img_0374

The home owner hires a firm of decorators because they have a reputation for quality.

Her first request is that the painter decorate the sitting room,  She would like the walls painted blue, the ceiling an off-white, the windows also off-white but the paint needs to be wipe-able to avoid finger prints, and the doors and trim should match the window color.

A story is an expression of a need

Acceptance Criteria are the notes from the discussion to help clarify the need

In this case the homeowner has specified a number of acceptance criteria:

  • Walls – blue
  • Ceiling off-white
  • Windows off-white but wipe-able paint
  • Trim same as windows

The acceptance criteria are details provided by the Product owner that would help the workman understand how to complete the job to the satisfaction of the Product Owner – in this case the home owner.

The acceptance criteria are details provided by the Product owner that would help the workman understand how to complete the job to the satisfaction of the Product Owner

The job can and probably should be broken down into smaller tasks (stories). Having just the windows painted has value, just the ceiling does too, just the trim and potentially each wall independently may have value although that may be harder to qualify with the Product Owner, depending on their needs.

Detail in Acceptance Criteria

What you will note though is that the acceptance criteria did not state that the areas to be painted must be professionally prepared and sanded, that a primer coat be applied and two top coats are applied.  They do not state that the carpets should be protected and that spills should be cleaned up and that there should be no paint on the glass and no wall paint on the ceiling, no ceiling paint on the walls or that the paint should fully cover the walls and be an even drip free finish.  In fact the Acceptance criteria make no mention of how the work should be completed at all.

Who is the audience of your Acceptance Criteria?

The Acceptance Criteria come from a conversation with the Product Owner, but you may also want to take technical notes from conversations with those that will do the work. E.g. if the contractor has an apprentice, it may be necessary to spell out to him/her the technical details mentioned above, what seems common sense to you and the Product Owner may not be as obvious to someone less experienced. But notes on implementation are not acceptance criteria in the same sense. The product Owner should not be expected to understand all the technical details, what is acceptable is always determined by the Product Owner.

If quality is not specified in the acceptance criteria

But that means I only need to worry about the happy path right? So I need to do a good job with the specified work but I don’t need to care about drips or mess or if I am painting the walls I don’t need to care about the ceiling after all I am only doing the happy path. I can ignore walls that are hidden behind furniture, I can do the job quicker if I don’t put down dust sheets and we can worry about cleaning up the mess later right?

Put like that it sounds silly doesn’t it, but that  is what you are suggesting if you don’t consider anything other than the happy path, the minimal amount is done but you are leaving a mess to clean up later.  If this is clearly understood and acceptable to the customer or that you have split a story like this to get feedback sooner there may be an exception but if you think that you can declare a story ‘done’ with a mess left to clear up later it is a recipe for a disappointed customer or a misleading impression that you have achieved more than you really have. Giving a sense of artificial progress may lead to disappointment later.

img_0376

Acceptance Criteria are comprehensive and exhaustive

If all acceptance criteria are met the PO/homeowner MUST accept the story even if the homeowner is not satisfied.   There is some crown moulding between the walls and the ceiling, it was not mentioned in the Acceptance Criteria and the decorator has painted it the wall colour, but the Home owner wanted it the same as the ceiling and thought it was obvious so had not mentioned it.  The decorator insists the job is done because the Acceptance Criteria are met.

This is actually a very common issue, Acceptance Criteria are often not comprehensive and there are ambiguities and omissions, so how do you handle them?  Assuming you are paying for the work on a time an materials basis the customer is the one that suffers, they will have to pay for the rework(or extra work), but it is generally the workman that gets frustrated, they believed they did a good job and so it is frustrating to have to repeat good work.   But the customer is not satisfied, and that should be the only thing that matters. Your goal as a quality workman is to satisfy your customer.  The job is not done until they are satisfied (assuming the request is reasonable)

It might be that the customer is willing to accept the work as it stands and agree to the repainting later. But more likely they will want it fixed before you move on to the next piece of work.

What is not acceptable is to refuse to make the changes because they were not explicit in the Acceptance Criteria.  The story card is an invitation to a conversation, the Acceptance Criteria are reminders of what has been discussed. At no point do Acceptance Criteria or the card become a sealed contract.

img_0373

Changes during a story

The painter is half way through painting the window and the Customer comes to check on progress. She sees the paint colour of the windows and decides it is too white, too stark and clinical and would like the colour changed to an off-white.  She understands that the rework will cost and the new materials will cost and she accepts this, but she is unhappy with the colour.

The painter responds: “But the thing is the A/C were clear about the colour, the shade was specified, I have spent a long time getting through the first half of this job and it is only fair that I finish it according to the A/C”  Then we can have a separate job to repaint it a different colour.  Frankly my metrics will look bad if this job takes 50% longer, it will look like I am slow. Do you know how frustrating it is to do a job and have it rejected..”

I have heard frequently how when a PO changes A/C the story should be completed as it is and a new story created for the revisions.  But any continuation on work that is not wanted is waste. The notion of continuing to work on something that is unwanted, and even worse billing the customer for that time, is just wrong.  If metrics are driving bad behaviour then the metrics are failing. If someone is demoralized because a PO has clarified their needs then they need to evaluate their understanding of Agile.   A full half of the Manifesto is:

Customer collaboration over contract negotiation
Responding to change over following a plan

If you are unwilling to accept and adapt to changes in A/C even late into development, then you really need to go back to basics and ask if you genuinely support Agile software development.  I am sorry if that sounds harsh but the notion that keeping devs happy and metrics pretty is more important than delivering the right thing for your customer is very frustrating for me to hear.

 If Acceptance Criteria are unclear we can choose what to do.

The homeowner has been pretty vague in her choice of colours, blue and off-white. So presumably we can choose whatever we want?

Clearly that is unrealistic.  What might be more reasonable would be to talk to the homeowner and say “We prefer this brand and type of paint and these are the available colours within that range can you pick one”   The homeowner may say, No I want a very specific Blue only available in this brand that needs to be imported from New Zealand.  In which case you should explain that such a choice will increase the cost and duration of the job and adds to the risk – being an unfamiliar material, it may need more coats etc.  If the homeowner understands and accepts those risks then it should be done, but if the homeowner can be presented with a less costly and less risky alternative then they may be willing to modify their request.

Ambiguity should trigger conversation it should not be an excuse for making assumptions.

Ambiguity should trigger conversation it should not be an excuse for making assumptions. The goal is a finish that the homeowner is happy with, the specifics are likely open to negotiation. But whilst you may present alternatives it is for the homeowner to make the decision.

Anything not stated doesn’t have to be done

There are two types of things not stated in the Acceptance Criteria that apply here, how we do the job and some of the specifics.

How: The Acceptance Criteria doesn’t explicitly say that we need a primer coat, but we know that for a quality job it needs to be done. The Acceptance Criteria doesn’t tell us which brushes to use, or how to paint to get a good neat coverage. The contractor may need to specify those to an apprentice, but the homeowner should not need to specify the tools to be used or how to do the job (unless that forms a particular part of the need)  You as the contractor may need to spell out those details to your apprentice, consider those sub-tasks of the story.  Prepare and protect work area; Sand surface, apply primer, apply first coat,  apply 2nd coat, clean up area, clean brushes etc.  But these are NOT Acceptance Criteria to be supplied by the home owner. They are about how to do the job not about the job that needs to be done. Sometimes these do overlap but generally we try to keep the how out of the request.

There are also some specifics that may not be mentioned, for example there is a recess around the fireplace but only 4 walls were mentioned.  Can I ignore the other surfaces?  Likely not, details may have been assumed, if there is doubt clarify with the homeowner. There is something fixed to the wall which is too close to be painted behind, but if not painted it would look odd. The Acceptance Criteria shouldn’t need to specify that you need to remove it and paint behind to do a good job. But again if there is any doubt clarify it with the homeowner.  The Acceptance Criteria will rarely be comprehensive and conversation will be necessary.

Specifics: The Acceptance Criteria should not specify how the job must be done

Normally we try not to specify how the job must be done, but there will be exceptions to this. The homeowner may have a need to decorate using traditional materials, and so may specify that particular tools are used – e.g. No power tools, no lead based paint. No synthetic materials in paint or tools.  Sometimes those requirements are not necessarily clear to you. The Customer may insist on 2 primer coats and 3 top coats.  Two more coats than you feel is necessary for a quality finish, but they insist are how the job should be done.  In those instances you may make recommendations or suggestions, and try to understand why they feel this is a requirement. But ultimately it is for them to decide – so long as they understand the additional cost and risk.

But again there are exceptions to this, for example the customer my request that you skip a primer coat and only apply a single top coat, or insists that you use low quality materials to save on cost. If you believe that this will result in a substandard job, then again you should explain your reasons and try to find an alternative and if necessary refuse to accept the job if you feel that the result would reflect badly on you.  Ideally it should be clear from the start what the expectations around quality of service are, but it may be necessary to re-clarify periodically if there is doubt.

Summary

  • In story terms, the story should express the need, what your goal is. It is the start of the conversation(not the end) for assessing how to satisfy that need.
  • The Acceptance criteria are simply notes to help remember that conversation, they do not form a contract.
  • Acceptance Criteria should never be considered absolute, immutable or comprehensive.  Uncertainty should be clarified with the Product Owner early and often.
  • You should respond to changes in Acceptance Criteria quickly, the quicker you respond the less waste there will be.
  • Acceptance Criteria do not normally express how to do the job, although you may note how you intend to do the job to illustrate to the PO to help clarify any ambiguities.

What about Gherkin?

You can’t have a discussion on Acceptance Criteria without mentioning Gherkin, Gherkin is simply a tool for expressing Acceptance Criteria in a standardised and hopefully clearer format. However, Acceptance Criteria Gherkin and Test scenario Gherkin are very often confused, and the Gherkin constraint may result in the focus shifting from the conversation about the user’s need, to how to use Gherkin and the user’s need may get lost.

Story Acceptance Criteria is also not the place for identifying all of the test scenarios and edge cases, it is about understanding the need of the customer.

Another common issue with Gherkin is that the precise nature of the format and terms implies that the Acceptance Criteria are absolute and non-negotiable which is the exact opposite of how they should be considered.  If you start to fall in to the trap of seeing the Gherkin as a contract (rather than notes on a conversation) then stop using it until you get in the habit of regular conversation with the Product Owner.

By all means practice with Gherkin until you get better, but if you remember that it is about capturing notes from a conversation with the PO and most certainly NOT negotiating the terms of a contract then it is a useful tool.  But personally I prefer not to use Gherkin in the initial conversations about Acceptance Criteria simply because it is not a natural way of thinking for many POs so the format constrains thinking and conversation and the frequency in which it is treated as an explicit contract undermines it’s value.   Once you have discussed the Acceptance Criteria converting them to Gherkin may be beneficial.

However, I prefer to see Gherkin used for Acceptance Testing where those writing the tests are familiar with the syntax and where precision is more important.
If you take nothing else from this, please remember that Accceptance Criteria are notes on a conversation, they are not clauses in a contract.

Accceptance Criteria are notes on a conversation, they are not clauses in a contract.

It’s my way or the highway…

The last few months have been pretty busy for me and so I have dropped out of the online community for a while. Over the Christmas break I had some free time and so I ventured back in, caught up on some reading and tried to get a feel for the common issues of the day.

What I found was post after post condemning just about all things ‘Agile’    

“Ban the use of Story points”

“Agile is dead”

“Scrum/KanBan should be sent to the scrap heap”

“We don’t need: Scrum Master/Product Owner/Agile Coach/QA” 

There were some even suggesting that Agile had run it’s course and we should go back to Waterfall.

I found all this very disheartening, on one hand most of these were from people presenting a new idea or new techniques, and it is sad to say but in our culture it seems the only way we seem to know how to sell something is by presenting everything else as bad or with Click Bait statements, we all want to get noticed.  But when did ‘Agile’ become so black and white?

For me Agile has always been first and foremost about inspecting and improving – finding better ways.  But that doesn’t automatically make anything that differs from your approach Bad.  And it certainly doesn’t make everything New to be Good.

There is not one Right Way.

In almost every case the examples/justifications were examples of poor implementations of Scrum/Kanban; incorrect use of Story Points; or a person being ineffective in a role, or in some cases there were teams that had matured to a point where they were no longer getting benefit from a tool or a role.

But not one of those examples makes the tool or the role Bad.   In each and every case the team should inspect and adapt, and identify improvements.  If one team decides that Story Points do not add value for them, that is great, that team has found a better way that they can deliver software.

But that doesn’t mean that other teams that find them effective are automatically doing it wrong. If you find you can use a tool effectively and it works for you, then use it. Just keep inspecting and improving.  If a tool doesn’t work for you or you find an alternative tool that works that is great too. But try to understand why you are using a tool, what is your desired outcome and is there a better way for you.

As an anecdote, I was using a drill to make holes to hang shelves, I carefully marked and measured and then drilled. A friend was with me and he picked up a cross-head screwdriver lined it up on the wall and hit it hard, punching a hole in the plasterboard wall, far quicker than I was doing with the drill.  The technique was great for him in that situation, but when faced with wood or brick it was not suitable, and in both cases I still needed to measure and mark.  

Tools are context AND user specific, what works for one user in one situation does not automatically work for all users in all situations.

The same goes for the roles argument, I agree that there are some teams that have the versatility, the right mix of people and the capability to work effectively without one or all of the roles, but that doesn’t mean they are an ideal we should all strive for. Many teams find they are far more effective with those roles, and I would consider that to be just as much an ideal state as the other. If your team is effective and improving then you are demonstrating an Agile mindset.  Our goal should be to improve how we deliver software, not strive for someone else’s idea of utopia. Concentrate on improving YOUR team rather than mimicking another team in a different situation.

Declaring your way the only way is not demonstrating an Agile Mindset.

Explain the benefits, do not attack the alternatives

If you find a way that you feel works well and you want to share it, then explain what problem it solved and why you felt it improved the way your team worked, share that example, but please don’t do so by declaring all other tools WRONG.  What is right for you may not be right for everyone. You will just sound like a Snake Oil salesman.

Don’t reinvent the wheel

Having said all that we don’t need to reinvent the wheel and discover everything ourselves. We can benefit from other people’s experience and advice.

Both Scrum and Kanban and any of the tools mentioned can be badly applied, but when implemented with the guidance of someone with a genuine Agile Mindset (rather than a blind by the book interpretation) they can be excellent foundations from which you can evolve, by inspecting and improving, they are not the end point but a safe and structured starting point.

The same applies to the named roles, having someone with an Agile Mindset that can help create a foundation of understanding of the roles and when and where they add value can provide a structure and consistency that allows you to grow from a starting point that has proven to be effective for many.

Do not stand still.

But most of all, whether it be Story Points or the need for a QA, inspect regularly, assess what problem you are trying to solve in terms of outcomes, if you feel a change will show improvement then experiment and review.  Small changes are generally preferred, it is easier to see the impact and easier to undo if the results are not what was expected. Understand what you are changing and why so that you can properly assess whether the change was beneficial.

I have seen teams conclude a Scrum Master/QA/Product Owner is not necessary after all they can cover the role themselves (usually as the result of cost saving measures or because they are presented with a false notion that good teams don’t need help). Sometimes this works, but more often the responsibilities are performed less effectively when distributed among the team and so the net result is a reduction in the effectiveness of the team.

There are certain expertise and mindsets that often come with a role that is not fully appreciated until it is gone. This generally and understandably gets neglected when it isn’t the core responsibility of the team members.

Let the team decide

If a team feels they need a change I’d have far more confidence than if the decision was made by someone with little or no exposure to the team, or on the back of reading a blog suggesting “good teams don’t use Scrum Masters/Story Points/Scrum/etc.”

Team leadership in Agile teams

badleader

Yesterday I had two people both of whom I have a lot of respect for, independently say that having a single person in charge of a team ‘works‘.

I was taken aback by this, partly the surprise that two people would say the same thing on the same day, but mostly because this goes against my experience and my opinions on good team leadership. This caused me to step back and reconsider my opinion and my reasons for it. For me there is a great pleasure in being challenged on my opinions especially ones that I was so sure of and so I have given it a lot of thought.

My experience

I have worked for other people directly or indirectly for more than 25 years, and I have managed teams myself, I have also coached quite a few teams – so was able to witness leadership from the sidelines. By a very quick count of those I can remember I would say that 70-80% of them were (in my personal opinion) poor leaders, there were a few that got the job done by force of will, or by leveraging authority, or by imposing death marches on the team. The organisation sometimes saw them as successful but the teams thought them dictators or bullies.

Many team leads simply were unwilling to see any perspective other than their own. Others who were clearly insecure at accepting other people’s ideas.  But there were a few good or even great leaders that didn’t see management as a tool for control but as a scaffold for building the team and achieving things, if only these could be cloned.

david-brent

So I am probably coloured by my experiences but the notion of one person in charge of the team fills me with dread.  and whilst I wholeheartedly agree that the model of a single leader can work with the right person, that does not mean that it will work in most cases or that those qualities are the norm, and it certainly doesn’t mean it will work as a model in every case. What is more I think those great leaders would thrive in an environment where they didn’t have defined authority- but more on that later.

I can only imagine that just as I have been coloured by my experiences my colleagues have equally been coloured by theirs but they have had the good fortune to see better leaders than I have and I would like to (and will) discuss this further with them to see why they feel this is a good approach and whether my instinctive reaction and poor experiences are in contrast to theirs.

“Leadership should mean giving control rather than taking control and creating leaders rather than forging followers.”

David Marquet

oh Captain, my Captain

The military is often used as an example of one named leader, but there is a distinction in the military and that is they have needs that are very different to a software team. Those differences are a need for independence and a desire for expedience in decision making: Military units will often need to operate independently without contact with their parent structure. So it may be necessary for a local arbiter. In a business environment it is rare that a disagreement is so urgent that it could not be referred up if there was a dispute with an impasse. The other aspect of a military organisation is that life and death decisions need to be made very quickly and so there may not be the luxury of time to debate and reach consensus.

However, even in military structures there are examples of leaders who take the view that they are the Product Owners, they will say this is what I want to achieve, you tell me how… and then the suggestions are made and the leader simply endorses the team’s advice (Make it so..). Naturally there is an element of accountability but the trust that this demonstrates in the team is significant in empowering the team and growing them.

This notion is explored more deeply in this book:  Turn this ship around

turn-ship

 

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Agile principle No 5.

We want conflict and debate

In software teams it is often the debate that produces the greatest thinking and ideas so stifling the debate is a negative. Having a single person making decisions stifles debate, it thwarts conversation, and it disempowers the team.  If a team is overruled often enough they will stop making suggestions, if one person becomes so myopic in their opinions it can make the team feel powerless and excluded.  Also where there is a defined leader they have a tendency to not be transparent, information is selectively shared (in both directions) and again lack of information impedes debate.  In short I believe that having a defined leader is in conflict with the Agile principles.

The best architectures, requirements, and designs emerge from self-organizing teams.

Agile principle No 11.

Merging the what and the how

Having the same person responsible for both the what (vision) and the how (implementation) stifles innovation. Rather than the team determining the best architecture and the best solution it becomes driven by a single individual. Again this is at conflict with the Agile principles, and whilst you may say that a good leader wouldn’t let this happen, experience and evidence is to the contrary. Power corrupts and if someone has the responsibility and authority it becomes hard for them not to use it especially if they perceive the team is making a mistake, and if teams are prevented from making mistakes they will stop experimenting.

We want balance

And this is where my agenda is.  Software development is a balance of content, quality, cost, value, consistency, team growth and a variety of other factors. It is rare or at least uncommon to have a single individual that is able to understand and balance those conflicting elements effectively on their own. More often a single individual prioritises one above the others, driving to a deadline, or gold plating a solution, or any other single aspect usually becomes prioritised at the expense of the rest.

I believe that a model where there is shared leadership and shared management between multiple roles solves many of these problems. Having someone focused on the what and others focused on the how and someone else focused on team improvement and consistency creates conflict (deliberately) but it also creates balance and it becomes a catalyst for debate.

We don’t want a single point of failure or a silo

If we make one person responsible for direction, implementation and team growth, we are putting all our eggs in one basket, if they are on leave or sick or move on then the impact can be significant. There can be so much knowledge tied up in one person they become indispensable.

leadership
Problems with the shared leadership model

First and foremost there is a cost. For small teams it may be difficult to find team members that have a natural affiliation to the balanced leadership model, with part time POs or coaches/scrum masters or where those roles are not named but the responsibilities are shared it can be tricky. But even then I would say that calling one person ‘Lead’ or ‘Manager’ or anything of that sort is destructive.  And the notion of combining Coach, PO and implementation into just one named role can lead to dysfunction. In many respects I wonder if the cost of additional named roles is worth it just to prevent the dysfunction a single leader creates. Or if the team is too small to warrant the explicit roles then get rid of named roles entirely – if a team is that small naming a leader should also be unnecessary, they ought to be able to self-organise within those boundaries.

This may sound hypocritical, after all I have spent a good proportion of my career with leader or manager in my job title.  But my experiences have been an internal conflict in that role. As a Software Development Manager you become the defacto Product Owner, Project Manager, architect and team coach. But there was always pressure from somewhere and normally that pressure was to the detriment of the team, when I challenged it, I did so a personal risk. Customer and senior management pressure to deliver, cuts costs and drive timelines meant that team growth became secondary, team welfare was deprioritised and making a safe place for teams to learn from mistakes was difficult to justify.  Some of that is company culture but I believe much of that comes from the pressure of responsibility and bestowing leadership carries pressure and expectation (sometimes real, sometimes assumed). And speaking as someone that has experienced it, I’d rather share that responsibility.

Conclusion

So after sleeping on the issue I am even more convinced that a named leader – whether it be Team lead, tech lead, manager, senior or nerd wrangler, goes against the principles of Agile, I believe it undermines self organising teams and leads to dysfunction and imbalance.  There absolutely are exceptions and there are some team leads that are effective, but I wonder if they would be just as effective or more so in a self-organising team structure. But there are more examples of ineffective team leads where the power corrupts and they dominate the team, stifle debate and innovation and disrupt or impede team growth.

In my very personal opinion the best leadership model is a balance of What, How and Team Improvement, and the more people those responsibilities are spread amongst the better. In practical terms I’d like to see a team with a PO to determine the What but a PO who actively engages with the team. A coach that is focused on the Team’s improvement and process improvement, and the rest of the team is responsible for the How.  Within the team there is no need to identify a senior or a leader they can work out amongst themselves how best to make decisions and titles get in the way.  This model may come with a cost and it may be difficult to get the balance right but in my experience this balance leads to the best results.

Ironically the examples of leaders that I have seen as being successful (as measured by both results and team morale) have voluntarily and noticeable made themselves servant leaders, stepping back and inviting the team in, choosing to give away authority and creating healthy debate and healthy conflict. So if that is how they lead effectively why not make that the model to start from?

Why I came to adopt an Agile mindset.

Ultimately it was because of seeing poor leaders disempower the team and abuse teams into death marches and drive poor design decisions that I came into Agile in the first place. I saw Agile as a method for empowering the teams and taking away abusive power from lone leaders. The stimulating of constructive conflict and healthy debate are so essential to the process that I object to any impediment to this on principle.

To my delight in most cases Agile has done that and so much more, in a creative environment like software the gains of self organised teams so massively outweigh the losses that result from a lack of a single clear leader that I am more confident in my opinion that the words ‘lead’ or ‘manager’ have no place in job titles on an agile team. I would love to trial and experiment to compare, but as much of this comes down to the personality of the people involved it is hard to do more than make subjective experience based assessments.

 

Why do we use WiP limits?

I participated in a great discussion this week on the use of WiP limits.  For those that don’t know, WiP stands for Work in Progress, and is a measure of how many activities you have started but not completed.

It is important to note that this is not a measure of how many tasks you are currently actively working on.  If I started a task but have become blocked, so I start another then my Work in Progress is 2 – even though I am only actively working on one. WiP is a measure of how many started but incomplete tasks I have.

For example: call-waiting or being put on hold during a phone call:  You are talking away and get another call so you switch to the second call without hanging up, and when you get another call you take that too, how many people can you have on hold at once?  You are only working on one call at a time, although you must remember the content and context of all those other calls. For the people still on hold while you have all these conversations I expect they are wishing you had a WiP limit.  Your WiP-Work In Progress is the sum of all active(incomplete) phone calls.

Limiting WiP

There are many reasons for limiting Work in Progress not least because I hate being put on hold.  I will go in to some later and it is likely that if you follow any type of Agile framework you already limit WiP although you may not be consciously aware of it.

If you have a backlog, then you are limiting WiP. You are consciously choosing not to start new work immediately but are prioritising it and organising it to work on later. It is likely that you are informally limiting your WiP according to what you feel you or your team can manage at a given time. It is important to realise that this is a WiP limit even though it may not be conscious or scientific.

If you follow Scrum: WiP is consciously and explicitly limited at Sprint Planning, often by estimating effort, or counting stories or calculating story points. The limit is generally set based on Velocity – our average achieved over previous sprints. If on average we finish 10 stories a Sprint, or we average 35 points, then that average is generally taken as the starting point for our WiP limit, we may choose to push for a few more, or if we are expecting to be slower due to vacation time, or known issues we may choose to commit to less. But in Scrum we don’t usually refer to it as a WiP limit. But that is exactly what it is.

KanBan is actually very similar, if we on average are completing 10 stories a week, then it is likely that we will consciously or subconsciously limit ourselves to only take on 10 new stories within a week, although in the case of KanBan this is not done in a Big Bang explicit decision but gradually over the measured period and is more a consequence than a plan (A Pull rather than a Push). We pull stories when we are ready and we pull at the pace we are working at, that just happens to be 10.

Slightly off-topic, but one of the crucial differences between Scrum and KanBan is that Scrum is a ‘Push’ model and KanBan is a ‘Pull’ model.  In Scrum we Push an amount of work to the board and spend the Sprint working to Remove(complete) it.  With KanBan we are aiming for a more steady amount of Work in Progress and will pull new work as current work is completed, which creates a smoother flow, but conversely lacks a unified time based goal or target.  But it is important to understand that both frameworks limit WiP and both focus on ‘completed’ work being the primary objective.

Why do we limit WiP?

I’d like to think it was obvious by now and I think the basic principle is, but there are nuances that may complicate things which may be where the cause for debate comes from.

At it’s simplistic level if I can only complete an average of 10 stories a week/sprint then starting an average of 20 a week without changing anything else is nuts, all that will happen is that on average 10 or more of those stories each week will remain incomplete and stay ‘in progress’ by the start of week 4 we will still have completed 30, but will have 50 now in progress.  Chances are by now we will actually go slower because we will be distracted and falling over ourselves trying to juggle more than we can possibly achieve.

Think of all those people on hold, growing frustrated at being ignored, and you trying to remember all those conversations, the phone rings again, can you cope with another caller on hold?

We limit WiP because we understand that by working only on what we can achieve, we can focus and be more effective.

Limiting WiP and WiP limits

“Ah but you have talked about Limiting WiP but you haven’t mentioned WiP limits” I hear you say…

And this is where I think the conversation really stems from and where we get into nuances.  KanBan began in manufacturing where work was passed from one workstation to another and there was a measurable flow through the system.   Limiting the production on one workstation so that it maintained pace with the entire system limits waste. Having one hyper-performing efficient widget maker that can produce widgets 4 times faster than they can possibly be used is wasted effort. And the same applies to a software process, we use WiP limits to regulate one part of the flow to maintain pace with the flow as a whole, the goal is to visualise bottlenecks and by visualising bottlenecks we can take steps to increase the flow of the whole system.

Other forms of WiP limit

But WiP limits can take many forms and are applicable to almost all aspects of life. The most common example used is a highway, when a road gets busy it slows down, when it gets very busy it grinds to a halt.  Limiting access actually speeds things up for everyone on the road, and ultimately more cars can get through far quicker.

But there are other less obvious WiP limits. A long-distance runner wants to increase her times, she starts fast but she runs out of energy and is slowing down near the end of the distance. By setting herself a slower time per mile early on (Pace is a form of WiP limit) she has a consistent speed and reserves energy so is able to run the full distance faster by slowing down during the early part of the race.

Are you dedicated to a single product/project?  That is a very low WiP limit of 1 project.

Do you use a calendar and try not to book two meetings at the same time, that is a very tight 1 item at a time WiP limit.

What about a budget?  Do you manage your finances as an individual or company. A budget is a WiP limit for your money, by limiting money spent on beer you have more available for clothes. By regulating your spending you can save for a holiday.  By remaining in credit at the bank you do not have to pay interest and so on.

Example of how to choose a WiP limit in a workflow

In the case of the widget maker, if the system can only use 10 widgets a day then we may set his WiP limit to 10, when he gets to 10 he is free to go and help someone else.  Suddenly rather than unused widgets we have an extra pair of hands to do other work.   But hold on! these widgets are easy to make and only take a short while to do, we could probably limit WiP to a lower limit and jump on the workstation as an when needed to produce more.  So how do we set the WiP limit?  My advice is not very scientific at this point.  Start by continue doing what you currently do and just watch, if your workstation/activity columns are sub divided in to doing and done, take a look on a regular basis and see where the biggest stacks are. If one column regularly has more cards on the done column than doing, it ‘may’ be a sign that you should reduce your WiP limit for that activity. Try it and see if it improves your flow.

The largest queues of done work are usually the area that needs limiting, but be aware of ‘bursts’ of activity, for example there may be a workstation that is only available for one day a week, in which case the queue for that workstation may need to be longer – or maybe you should be asking for more regular access to the workstation. But when imposing limits do it gradually and monitor to see if it improves the flow.

Anything in a done column is normally waste, if it is done and not in production that effort cost you money and is just sat there.  Sometimes that makes sense but the car industry learned that complete cars sat in storage amounted to $millions of wasted investment, that components stockpiled in advance was essentially big piles of cash that could be used more effectively, we can learn the same.

What I am saying is that a WiP limit being reached is a conversation trigger, a long queue is a conversation trigger, and so on. With so many things in Agile we create early warning systems to create conversations and make decisions when it is necessary.  We make small changes to the process and watch, we see what changes and if it is better we carry on, but look for another new small improvement.

Summary

WiP limits are not unique to KanBan, and like it or not you are already limiting your work and activities in all aspects of your daily life, you just perhaps didn’t realize it.  In the context of a KanBan board we do not arbitrarily impose a WiP limit because we can or because it is fun. We impose a limit when we feel it adds value, normally where we see a queue of completed work growing faster than it is being consumed. We limit various stages of the work because our goal is the output of the system (the whole team) and not the perceived utilization of individuals.  One team member being 100% occupied all day producing something that will sit untouched for a week is not efficient.

We are not trying to manage a system where our goal is to keep busy a group of individuals, our goal is to create a cooperative and coordinated team working towards a common purpose in the most effective way possible. A WiP limit is just one of many tools that can be used to enhance the prioritisation of work and focus the team on the true goal.

 

 

 

Is structure supportive or restrictive?

I have been engaged in a discussion along these lines with a colleague over the last few days, it is a subject we both are interested in and one that I have been very much on the fence. 

I began from a position of a very strong belief that structure was beneficial and that it provides a scaffolding that enables teams to grow. But my colleague took the view that once in place the structure becomes at best a crutch and at worst a barrier to self-organisation and agility. 

This conversation is the basis for the usual discussion on whether a Scrum Master is necessary or should they make themselves redundant.  Or – Do we need a designated product owner or simply a better understanding of product ownership? 

Even to the point of whether there are any designated roles within the team, do we need to identify Devs, Testers, QAs, UX, BAs etc etc or can we consider all “Team Members” that are ‘T’ shaped, that is to say that whilst they possess specialty skills they are first and foremost team players able to cover most of the core software delivery skills.

Baseball

I am (very)English, so my knowledge of baseball is minimal. But today I had someone explain the finer points of ERA and ERA+ and some of the other joys of the statistics of baseball. I can sense you preparing yawns at this point so I shall go no further. But the conversation progressed to “Designated Hitters” players who do not field, they have a specialist skill, or are able to stand in to save the pitcher from batting (another dedicated role?)  I may have misunderstood this, but it was described as an “abomination to the sport” by someone that clearly believes that it is a sport where the players must participate beyond their specialty.  The converse argument presumably is that if you have exceptionally skilled specialists why should they need to participate in other roles – the team is more effective as a whole by them specializing.  Okay so I am stretching the analogy a little, but the argument holds.

Should we specialize

Specialism may aid the efficiency or the effectiveness of the team, but is it still a team sport and can a team ‘self-organize’ if there a members that can only fulfil a specialty role?

And let us suppose that we have two expert catchers, and they have no batting or fielding skills, there is no benefit to having both of them on the team. And what if our best catcher is also a good outfielder, do we use our second best catcher in the catcher position because he only has the one skill?

My view started with the opinion that the most effective teams I have worked with had both a Coach and a Product Owner, that specialism in those roles is necessary to achieve the focus necessary to be optimally effective, both individually and for the team. In the case of the coach his input magnifies the team at a higher rate than adding another team member and for most medium or larger teams the product ownership tasks are demanding and require one person to have a view on many aspects of it – albeit that the team can and should be involved as much as possible.

I stand by this position, if our only goal was the effectiveness of an average team in average circumstances.

The problem with this situation is that there is an implied hierarchy, and that the appointed people in those roles may not be the best choice, that members of the team if enabled may be able to take on some or even all of those responsibilities.  Essentially those enabling roles also become limiting factors to growth.

So long as there is a coach there, some of the team will use them as a crutch, the implied hierarchy may disguise or suppress dysfunctions, the coach may be more valuable elsewhere or in another role but is constrained.  The same for Product owner, they can easily become a bottleneck as much as a facilitator/enabler. And let’s be frank how often is the workload for a coach or a product owner approximately 1 full-time employee. Chances are one or the other or even both will be grossly over or underworked and consequently stressed or bored.

The teams will never become completely self organising in those situations. Not until enough of the team are skilled and effective in those roles and are able to internally organize themselves. And that can and will only happen if they are allowed to grow into that. 

What to do?

But of course just starting on day one and say “go organize yourselves” would be madness in most circumstances, the skills are not off the shelf skills and generally come more from experience than teaching.  But having guidelines or even common practice of teams of that structure creates an expectation of what ‘good’ looks like, and it becomes a self-perpetuating concept.

My belief and I am conscious I may be a minority here, is that we provide scaffolding, but from the outset make it clear that the end goal is independence from constraint, that the structure presented is to enable learning and will eventually be removed.  That we take our ‘T’ piece team members and we encourage them to diversify further, to become capable and aware of more skills.  We support specialism, specialty skills ARE valuable but all rounders are more valuable.

Say no to designated batters…

We don’t want designated batters, we are a team, and in a team we still function near to 100% if/when we lose a player. If that means we lose some specialists because we favor all rounders, perhaps that is a risk we have to take.  I don’t believe this means that we compromise on quality, it just means being more open to learning other skills.

Coaches should focus as much on teaching and enabling independence as they do on effectiveness.  The pragmatist in me still believes that we are a long way from this ideal, and that in most cases the teams will likely organize themselves with designated product owners, QA, UX and Devs, as inevitably there will be some people that are more skilled than others, but I would like to see us blurring those lines to the point where it is difficult for an outsider to recognize. 

The teams will likely still desire coaching and support in difficult situations, I am still of the opinion that we all benefit from coaching (even/especially the coaches), but if this can be owned by the team and it can be their choice as to who and how performs the roles we will be much closer to the goal of self-organization.

A lofty goal and one that will likely have a few hiccups along the way, but  I am beginning to believe that we can use the scaffolding of structure to be a stepping stone to self-organization.

     

Project Management Mistakes

I found an interesting link discussing common Project Management problems and suggested solutions, and I found myself questioning the advice given…

http://www.cio.com/article/2391872/project-management/12-common-project-management-mistakes–and-how-to-avoid-them.html

So many projects, so much mismanagement. That’s the refrain of many IT executives. Indeed, even with project management software, IT projects often wind up taking longer (much longer) than planned and costing more than budgeted.

I have previously covered the issue of how many failed projects there actually are, the proportions are really quite frightening: Most projects will fail by conventional measures, they will go over budget, be late or the scope will change, even with ‘good’ planning and contingency. So an assessment of “why?” is a great idea, but many companies are still stuck in a rut of doing the same thing and expecting different results.

The Survey in the link above and the proposed solutions is nice to see, but to me it felt as if the respondents were trying to solve problems by doing the same things that have failed previously – only suggesting that if they had done it ‘better’ it would be different, rather than considering that maybe the process that was at fault?  I wondered how applying an Agile perspective might offer different solutions to try.

I do not intend to be (too) critical of the original responses, they were clearly made by experts in their field and may very well be the right answer, but I have taken each issue – all of which are common project management issues, and I have applied an Agile head when offering a solution.

I don’t claim my solutions are right or better, but they may offer a slightly different perspective on persistent problems. And reflect how I would advise the problems should be resolved.

 

Project Management Mistake No. 1: Not Assigning the Right Person to Manage the Project.

Typically during resource allocation, most of the effort is focused on finding the right resources rather than finding the right project manager. Indeed, too often project managers get picked based on availability, not necessarily on skill set. However, an inadequately trained and/or inexperienced project manager can doom a project.

Traditional PM Solution:

Choose a project manager whose skill set(s) match the project requirements.

Agile solution:

1) Ask whether the project even needs a Project Manager, it may be that the content and scope could be ‘owned’ by a single ‘Product Owner’  When it comes to a project that involves integrating many independent components from different sources and there isn’t a clear hierarchy or dependency then a Project Manager may make sense, but where the project is delivery of a product increment, or there is a clear hierarchy and dependencies it is not clear to me what value if any that a PM adds, it becomes an extra layer of bureaucracy but no added value.

2) However the traditional answer applies in an Agile environment. Finding a Product Owner that has the right knowledge and skill set is vital, as is empower them appropriately. Finally have them focused entirely on this one and only product. Multi-tasking will generally lead to problems with one or both projects.

Project Management Mistake No. 2: Failing to Get Everyone on the Team Behind the Project.

Too often, projects are doomed to fail because they didn’t get enough support from the departments and people affected by and involved in the project. Either managers: 1) Didn’t make clear what everyone’s role was. 2) Didn’t describe the personal payoff everyone would get when the project was completed successfully. 3) Didn’t tell how each person’s contributions to the project would be evaluated. And/or 4) Failed to generate a sense of urgency about the project, leading the team to think business as usual will be fine.

Traditional PM Solution:

The project manager should start by calling the team together (being certain to include off-site staff via the best technology available) and delivering a presentation about the project and its significance in a way that gets everybody fired up.

Agile solution:

1) The Product owner should share the vision with the team, show how their part fits in with the big picture. The vision is crucial and should be clear to everyone. (just as above)

2) Where possible have team members dedicated to the project, this immediately builds ownership and commitment, have them co-located with colleagues and build a team. Motivation to team mates is more effective, more consistent and has greater longevity than that which can be created to a project.

3) Have the team involved in setting goals and expectations; the more involved they are the more they will buy-in to the project. Give them ownership of the design and the level of quality, a self-set target is more meaningful than an imposed one.

4) Discussing Personal payoff is not helpful, we are trying to build a team, in software projects like any cognitive task both carrot and stick are counter product and can be demonstrated to reduce productivity. It is far better to build a good team and share a vision, a well-motivated team does not need a sense of payoff, successful delivery of a product is motivation enough. A shared purpose and shared success.

5) Again a sense of urgency is not a helpful tool for motivating software teams, ‘Urgency’ should be reflected in prioritization not pressure or deadlines. An appropriately motivated team should work at a sustainable pace.  Let’s talk in terms of priority: Urgency is a reflection of poor management and poor planning, projecting that failure on to the team is in my opinion a sign of failure of management.

One final note – “Failed to generate a sense of urgency about the project, leading the team to think business as usual will be fine”   I find this to be a very bizarre comment, in my opinion “Business as Usual” is fine, in fact business as usual is great. If I have a team that works at a sustainable and predictable pace that is the holy grail for a project manager, or it should be. A known quantity, and one that can run and run and run like the Duracell bunny is what any project manager should desire.

Why would anyone thing that driving a team into the ground to meet an urgent deadline, followed by a crash of exhaustion, staff potentially off with stress, or quitting, or any of the other consequences of deliberately overworking and pressuring staff is actually a good thing?

Whilst meeting an unrealistic deadline set by someone outside of the team may well be the priority of a PM, it is naïve to assume you can move teams from one project to the next without a break always expecting them to work with a sense of urgency.  It would be far better to think of the team as a machine that takes a while to get up to speed, whilst you may be able to stress the engine and push it to the limit, to do so regularly or for prolonged periods will cause damage. Whereas a good engine run at a sustainable pace can run for far longer.

Ultimately, It comes down to a question of respect. If you treat your team right, they will work well for far longer and be far more productive in the long-term.

 

Project Management Mistake No. 3: Not Getting Executive Buy-in.

Traditional PM Solution:

Somebody at the higher levels of the organization needs to own the project from start to finish and be personally vested in its success, When a project has no clear head, things tend to fall apart.

Agile solution:

1) A single Product owner should be empowered, and personally vested in the success and assigned exclusively for the duration. If the Product Owner cannot be sufficiently empowered to achieve success, then your organization has more serious issues.

2) Not all projects need a senior sponsor, but they do need support appropriate to the project.

3) Senior sponsorship for the way you work is vital – By which I mean Framework – in this case Agile. The organisation needs to be behind the delivery method. If the project is necessary then the project leader needs to have the backing of the company to get it done. Any block to agile delivery needs to be aggressively unblocked and sometimes this required uncomfortable change in attitudes, and that will require senior sponsorship.

 

Project Management Mistake No. 4: Putting Too Many Projects into Production at Once.

Most managers think that they can get more done by starting all projects at once, but in reality, it’s counterproductive. Multitasking slows people down, hurts quality and, worst of all, the delays caused by multitasking cascade and multiply through the organization as people further down the line wait for others to finish prerequisite tasks.

Traditional PM Solution:

To stop these productivity losses, a good first step is to reduce work in progress (WIP) by 25-50 percent. This reduces the back and forth and makes managers and experts more responsive in dealing with issues and questions. Though counter-intuitive, reducing the number of open projects by 25-50 percent can double task completion rates.

Agile solution:

The same as above: reduce WIP, far too often we resort to claiming credit for starting work, or for claiming it is in progress.  The only metric that matters is completed work.  If limiting the number of projects on the go, results in more projects being completed then what are you waiting for?

I’d like to write more on this topic, I feel this is so crucial to success, the number of times teams are held up because of competing demands on networks teams, DBAs or deployment pipelines or any number of other critical resources. The impact of these are often unmeasured, but simply reducing the number of concurrent projects relieves the context switching and demand on these resources. Which is an immediate easy win.

But more that if you can deliver 4 projects in 12 months, why not deliver 2 of them in 6 months, and then 2 in the following 6 months.  That is two projects delivered 6 months early without any additional work and without delaying anything, you may even find they get done quicker.

Project Management Mistake No. 5: Lack of (Regular) Communication/Meetings.

Communication is the most important factor of successful project management. Without regularly and clearly communicating, the project will fall apart.

Traditional PM Solution:

Pick a day and time to meet each week (either virtually or in person) that works for the team (not just the project manager) — and stick with it. Having specific days and times scheduled, in advance, helps to keep everyone on the same page and keeps the project flowing.

Agile solution:

Meet daily, co-locate the team to reduce further any delay in communication.  Use information radiators (Whiteboards to the rest of us) to prominently display  useful and pertinent information.  If the information is useful you need it now, if you can wait a week for it, it probably isn’t that important.

Communication in Agile is crucial, anything that can be done to reduce the barriers to communication should be considered a priority, getting team members and those peripheral to the team communicating effectively is vital. Co-locate where possible, a daily stand-up is a scheduled opportunity to get together and share, but for anything critical even a daily meet up is not quick enough. But communication should be useful, timely and concise.

Project Management Mistake No. 6: Not Being Specific Enough with the Scope/Allowing the Scope to Frequently Change.

Any project that doesn’t have an ultra-clear goal is doomed, scope change is one of the most dangerous things that can happen to your project. If not handled properly it can lead to cost and time overrun. Even something small, like changing the color of a logo or adding a page to a website might cause unexpected delays.

Traditional PM Solution:

Define the scope of your project from the outset and monitor the project regularly to make sure you and your team are keeping within the scope. And to avoid delays and deviation from the original scope, track change requests separately from the original project scope, and provide estimates on how it will affect the schedule and get explicit customer/stakeholder approval for each change.

Agile solution:

“Even something small like changing the color of a logo might cause unexpected delays”   Wow!  And the solution is to “Avoid delays and deviation from original scope”  Wow!

I am utterly stunned by this problem and the response.  First everyone involved in a project does or should understand that Change causes delays, any client that expects to be able to change a Logo or add a page without a consequential delay, is extraordinarily naïve or is being misled.  Very simply work takes time, sometimes even removing work takes time.  A product Owner or PM should be able to candidly discuss this with the client, if the client is asking for change they should be made aware of the impact and that information should help shape their decision.  If you cannot have this conversation then there is insufficient trust between you and the client, and rigorously enforcing terms of the original contract is not going to promote trust.

In my opinion the response is shocking, just who is the Client here?  If the client has changed their Logo, then who would consider it sensible to plough on with a solution that is wrong? Refusing to accept change is not working for your customer, it is self-serving and ultimately futile.  This stubborn refusal to accept change is the primary reason Agile has been the huge success it has, because the customer is respected.  In Waterfall the goal is to conform to a contract, in Agile the goal is to give the customer what they want. The difference between the two is a happy customer and an irritated customer seeking a new supplier.

Example: If we consider an extension to a house, upfront I may have architectural drawings, and building plans, and I may get a builders quote based on those plans.  But as the build progresses I decide that I’d like to change the position of a window or I change my mind about the type of tiles, or kitchen units. As the customer that is my prerogative.

Situation A:  Builder says, “No! that is not what we agreed, you must stick with the plan and keep the materials you specified.  If you want to change this, you must wait until we are done, then rip out the work and redo it later.”

Situation B: Builder says, “Yes! But it is not what our estimate was based on, changing the plan and materials may increase the cost, and may take a little longer. So long as you are comfortable with the impact we are able to accommodate your requests.”

And Just for fun – and this generally doesn’t work so well for building work where planning permission is needed upfront but still…

Situation C: Builder says, “Let’s build the initial framework and you can defer making the decisions about the layout and internal fixtures until later, when you are better able to envision the situation.

Project Management Mistake No. 7: Providing Aggressive/Overly Optimistic Timelines.

The intentions are noble, as project managers are often trying to keep their clients happy. But missing deadline after deadline will only lead to distrust and aggravation on the part of your client.

Traditional PM Solution:

Good project management software will allow you to manage many work items and the bandwidth of available resources. However, it’s still important to add a buffer providing some extra time and money to your project, especially in the world of technology.

Agile Solution:

The proposal of Better software, and more micromanagement and adding contingency to counter optimistic timelines, is the opposite of good agile practices.    Once again I completely disagree with the proposed solution.

Solution 1) If the timelines are unrealistic this should be addressed, the team (dev or management team, or customers) should assess why they are coming up with unrealistic estimates, and modify behaviour accordingly.  Discuss why a timeline is needed, and plan accordingly.  If we must meet a specific date then we plan the solution accordingly, if we must keep to a certain budget, we can plan the solution accordingly, but an estimate is not the same as a deadline. See blog post…

Solution 2) Rather than adding buffers and contingency, how about prioritizing content and being flexible with the scope to meet a timeline if the timeline is critical, or being flexible with the time.  It is a controversial comment but I find the routine practice of PMs padding estimates or surreptitiously adding contingency is counterproductive, it causes mistrust, and is ultimately futile as management will react by demanding earlier delivery believing that estimates are padded.  I’d much prefer to be open an honest, and build trust, I keep management informed of progress and allow them to make decisions on true and upto date information.

Solution 3) Fancy software doesn’t help. The more you micromanage the less productive the team becomes.  For a former software developer and general technophile, when it comes to project management I’d actually prefer to have no software tool at all.  A Kanban board and a backlog of stories on Index cards is actually very powerful, software has value in some circumstances but most of the time the simple approach is sufficient and clear to everyone involved.

Project Management Mistake No. 8:

Not Being Flexible. While you may think of your project plan as your bible, telling you what needs to be done, by whom, and when to do it to get to your goal. Don’t hesitate to listen to new information and suggestions that come up along the way.

Traditional PM Solution:

It’s good at various intervals to step back and take a fresh look at the overall project, review how things have gone so far, and how you can improve your future work based on what’s already changed along the way. That doesn’t mean you should or need to constantly make changes,  just be open to suggestions if they help the project.

Agile response:

Schedule regular retrospectives, make the act of trying to improve a regular part of your job. Actively look for ways to improve, a passive ‘being open to change’ is not enough. We need to seek to improve and have a willingness to continually find even small ways to grow. Many small improvements can lead to significant benefits.

Project Management Mistake No. 9: Not Having a System in Place for Approving and Tracking Changes.

Often, success or failure of a project hinges on the changes that occur after it begins. However, all too often, there is no system in place for approving and tracking changes.

Traditional PM Solution:

Having a clear process that must be followed is the best way to ensure the pertinent details: how much it will cost, why it is necessary, the impact on the overall project etc., are known before the change is approved. It’s also extremely effective for auditing performance during and after project completion.”

Agile solution:

Change is a part of software development, no amount of planning can ever reveal everything, there will be change, so plan for it from the outset.  Prioritise work rather than plan in detail, allow for priorities to change and expect them to change. Allow for new work to emerge, and consider and plan for the possibility of failure.   As with the traditional PM approach, why; cost and impact need to be considered, but these are a factor of priority. Any heavy weight review process is unnecessary.

Failure is deemed bad in all circumstances, but that is not the case, to fail early may actually save significant costs compared to failing later. This should he heralded a success, but too often all failure is considered bad. Failure can lead to successes later. Not learning from failure or continuing along a failing path is the real waste. But too often any failure is not tolerated and this can be very damaging.

Project Management Mistake No. 10: Micromanaging Projects.

Don’t babysit, It’s very common for budding project managers to treat their job like an enforcer, policing the project team for progress and updates.

Traditional PM Solution:

Instead of babysitting the project team, let it be known from the start [i.e., the kick-off meeting] that there will be regularly scheduled updates for the duration of the project. This lets your team know that status updates and progress are expected from them weekly and will encourage them to vocalize any issues or delays in advance.

Agile Solution:

Don’t allow the Project Manager or Product Owner to micro-manage, it is the job of the Scrum Master to coach the team to manage themselves and then the SM is to run protection – keeping the wolves at bay. PMs micromanaging is rarely beneficial and is generally damaging. The saying goes that you should hire the right people to do the job, and once you have hired them, trust them to do the job right.  If you have hired the wrong person no amount of micromanaging will help, and if you have the hired the right person micromanaging will only hurt.

Project Management Mistake No. 11: Expecting Software to Solve All Your Project Management Issues.

I’ve seen people throw software at problems all too often, and though projects become enumerated and more visible, the underlying process is still broken,” “What you end up with in that case is a potentially costly piece of software only serving as a checklist of projects in motion without any thought given to advancing each project/milestone effectively.

Traditional PM Solution:

Choose project management software wisely — something all members of the team will be comfortable using. Then make sure to train users properly and set up a system for tracking projects. Above all, don’t let human capital be “overshadowed by the allure of software solutions’!”

Agile Solution:

Fancy software doesn’t help. The more you micromanage the less productive the team becomes.  When it comes to software project management I’d actually prefer to have no software tool at all.  A Kanban board and a backlog of stories on Index cards is actually very powerful, software has value in some circumstances but most of the time the simple approach is sufficient and clear to everyone involved.  Naturally many projects involve more than a single stream of software and in that case a software tool may be useful, so long as it doesn’t interfere with the software development streams.

If we limit scope to be a software development stream, then simple metrics on backlog, cumulative flow and perhaps velocity should be more than enough to check progress towards milestones. But in this case the Product Owner is the best source for the health of a software project.

 

Project Management Mistake No. 12: Not Having a Metric for Defining Success.

Traditional PM Solution:

The very first thing a project manager should do is ensure he understands what the end users will consider a successful completion to the project,” Understanding what will make a project successful…ensures that when the project is completed [all] parties walk away satisfied.

Agile Solution:

Very similar, a clear Vision for the project is key, but a vision is not a set of requirements it is a concept.  Ensure that the Product Owner and the team understand the vision and any intermediate milestones.  But the goal is satisfaction of the customer,  that is the only metric that matters. Ongoing conversation to ensure they are satisfied with the progress is essential, regular reviews and conversations to ensure your solution is meeting their needs.  This is not an exercise in checking off items on a contract, it is about delivering the right solution to the customer.

 

Summary

It surprised me how different an agile approach is, I had expected far more overlap, after all Project Management is as old as the hills. Some solutions are common to both approaches but even then the approach whilst similar seemed to have a different goal.

But what struck me most was how Traditional solutions fell back to a desire for more control: control the scope, control the team, and control the customer. Whereas Agile was about building a team, responding to the customer and guiding not controlling the delivery. The perception of control is such a fallacy when dealing with a customers evolving needs and the unknowns of software development.

 

A quick Star Wars quote to finish:

“The more you tighten your grip, Tarkin, the more star systems will slip through your fingers.”

Could it be as simple as that? As a Project Manager it seems that the more control you try to exert, the less real control you have on the delivery, but by accepting a little Agility:- whilst it may seem to be relinquishing control you are actually far better able to steer the project.

What is the Minimum Viable Product?

A question came up this week following a discussion on story writing that I think bears further discussion.

What really is the Minimum Viable Product? 

To explain my thoughts I will use the building of a Skyscraper as an analogy.

The project vision is to build the UK’s tallest building. To achieve that it must be over 1000ft tall and 88 floors.

What is the MVP?  There are many possible answers to this, but the first two responses that spring to mind are:

1                 My MVP is over 1000ft tall and 88 floors, without that it simply fails to meet my vision.

But let’s say I underestimated the costs and after 65 floors I run out of money, I have been agile and each of the floors was a complete deliverable, the building is perfectly functional at 65 floors, in fact it was probably functional at 1 floor.   So surely at any point it was an MVP?

construction

2                 My absolute worst case scenario MVP a single floor

This is where things get confusing.    No serious customer would consider a 1 floor building with massive land costs and hugely expensive foundations ‘Viable’  the project would never be signed off.  As such this is not viable.  However, I’d still suggest aiming for the ability to deliver in phases, e.g. a delivery after each floor.

In this situation I’d say an MVP is the minimum that a customer would accept. And that is a conversation, would he agree to a MVP of 88 floors but a first phase goal of 20 floors, with the ability to expand later? As you can imagine the MVP is likely to change according to the circumstances. Our goal is to delight the customer but our plan is to build the product in such a way that if at any point he is satisfied or better yet delighted, we can ‘deliver’ immediately.

skyline

My point – hopefully not lost in the mix is that an MVP is about thinking about the minimum that a customer would find useful – usually this is closely related to the original vision. In the case of this building – what if the last 10 floors were empty unfinished shells? or similarly we leave the project in a state where it is valuable as is and the Vision can be achieved in a future project  – The building still will meet the vision and those floors could be finished later?

Having an MVP in mind is useful, it may help with some decisions, but every project is different and MVP will likely evolve with the project. A good Product Owner or BA will be able to work out what is the true MVP and why. The PO can focus on the customers evolving needs so that the customer gets the best ROI at each stage, but most of all they will be aware of what would be the solution that would delight the customer.

An MVP is a tool like any other, in most cases it is a fall back position, not the goal.