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.

Back to Scrumdamentals

It has been a pretty difficult few weeks for me, busy, busy, busy and frankly more management than coaching. Cue air violins!

In the division I am working in there are three Scrum Teams, up until now I have been responsible for two and the third has tried a number of ways to accommodate the lack of a Scrum Master, one member of the team took on the role for a while on top of their other duties and a Project Manager took it on for a while, again on top of other duties. But these part-time roles have been unsuccessful and I was asked to take on a third team.

I was very reluctant to dilute my other responsibilities and expressed this to the department head, and so we agreed it will be temporary and I’ll be training a new Scrum Master for that team to take over in a few months. Which is great but also means I now have responsibility for three teams and training of a new SM, and we will be losing one extremely valuable member from a team.  As I say Cue violins, but my concern is not just workload, it is the teams themselves, one of the teams already feels I don’t spend enough time with them and spreading me thinner wont help with that. So that is problem 1, 2 and 3 but my other and now more serious problem is that the final team is in a state of flux.  The Product Owner has moved on to a new role and it has been difficult to find a replacement.

A Product Owner is a difficult role, and seemingly undesirable. The product is essentially a suite of very closely integrated sub-products with what is intended to be a single front end, the product cannot easily be split because of how closely coupled it is, but the system is so complex there are at least three Business Analysts and an Architect who when combined cover the understanding of the system. The chief architect is ultimately the product owner, he makes the call on the roadmap and the priority of content into the system, but doesn’t have visibility of the fine detail at an individual story level, that is down to the BAs who are doing it on top of their other responsibilities. So prioritisation is at Epic level, with the BAs prioritising the smaller individual stories.

And to cap it all we have hit a spate of recruitment and retention issues. We had decided that the volume of work was such that we would expand and have a second team on this product, but over the last few months two contractors have left, primarily for family reasons (and higher rates) and a very experienced member of the team has got a promotion so he too has left, and as I say another team member has volunteered to be trained as a ScrumMaster, all told a major impact on one relatively small team. So I have been very very busy recruiting (30+ interviews over the last 3 weeks). I have spent the last couple of weeks almost exclusively interviewing and screening CVs. Thankfully offers have been made and I’m hopeful we will have a new team up and running in a few weeks.

But it is essentially a brand new team; a new Product Owner Dynamic; and a major new piece of work.  A new Product Owner, and 3 new proxy product owners(Business analysts) a new Scrum team comprised of a former tester and 4 new former developers (I say former as once in a Scrum team I hope they will all see themselves as a cross-functional team).  All this got me thinking. At first I was anxious about the disruption, I am also anxious that the Product Owner representatives are not dedicated to what is a major product, but after some thought I realise that disruption is the wrong word, the team can’t really be disrupted, there isn’t enough left of the old team to call it a disruption.

New Structure

What we have is a fantastic opportunity, we can create and build a new team from scratch. It is not often you get to join a team at the beginning and are able to shape it to be the team you want to be a part of, usually it is a case of fitting in. But the new team members are joining a high profile new product together and get to shape it as we collectively see fit.

All of the team have had some exposure to some form of agile development they seem strong developers and eager to use Agile, so there will be a degree of Scrum training and coaching but for me the crucial task is to build a team first, get them working together, learning strengths and weaknesses and growing into a team.  I still have a lot of worries, especially about growing a new team whilst also supporting the existing teams, I cannot give the teams as much attention as I would like, but I am actually pretty excited about the prospect of helping build a new agile team.

I have been trying to think of a good place to start, no doubt the level of Scrum training will vary so I thought that I might try a combined Scrum Training and team building exercise. My train of thought led me to http://www.lego4scrum.com/  it is my hope that when they get on board, I will set up a session for them and mix it up with the other existing Scrum Teams. I plan to write up a review after the event which I will post here.

Product Owner Role – Overview

I have been asked to give a summary introduction of the responsibilities of the product owner role to a budding Product Owner.  They are due to go on a training course in around six-weeks so this is much more of a high level introduction to the expectations of the role.

Product Owner Overview

I began by outlining some of the core expectation of the role, the delivery expectations and the importance of the role in the process.

But the crucial and generally time consuming aspect of the role is the co-ordination, interaction and management of the stakeholders.

Product Owner Stakeholders

The Product Owner is one of the hardest roles in Scrum, being lobbied by users, the business, the team and others.  Giving time to users to properly understand requirements, understanding the goal and vision of the project/product. Identifying priorities. Being available to the team. Making decisions and all the while knowing you are the single wring-able neck, the one person responsible for the success of the project.

The Product Owner is involved in writing stories, planning releases, setting the product vision, the sprint goals and constantly ensuring that the backlog is up to date and prioritised.

It is not for the feint of heart.