STL Agile Open Space 2016 – Self-organising teams

I spent Friday at the St Louis – Agile Open Space 2016.   [On Twitter see #stlopenspace ]

It was a fantastic day with a great group of friendly and enthusiastic people all eager to learn something new, I went along with a few of the other coaches from Asynchrony. All of us expecting something different from the event, being new to the area for me it was as much about meeting a few people as it was about learning, but it was such a good experience. And as it always seems to be the case, I learn a little and in doing so I discover how much more there is that I didn’t know that I didn’t know.  The sheer wealth of my ignorance grows daily, but I learn something knew and I share what I can, and hopefully it balances eventually.

Self-organising teams

Did you know Dr Seuss was in favour of self organising teams?

There were a number of topics and discussions that drew my attention but the first that I want to share was a discussion on shelf-organising teams. A topic I am always very keen to discuss. The topic was raised by a Scrum Master whose team was moving in this direction and so she was asking for advice and to discuss experiences. Both internally to the team and how this would work with the rest of the organization.

The conversation was free flowing and we covered all sorts of aspects of the concept, as you can see from the post-it summary the conversation touched on whether a self-organising team should have a hiring budget and should be empowered to hire their own team, what the role of a Scrum Master should be in this environment. Even a somewhat controversial discussion on whether the team should be able to choose it’s own metrics and forcasting style when they are ‘consumed’ outside of the team.

Can there really be self-organising teams

The first discussion was one of hierarchy, there was an ‘acceptance’ for lack of a better word- by some of the group, that there is an actual or implied hierarchy and that a team has a manager or the PO or the Scrum Master, or the Team Lead is “in-charge”  there was a variety of experiences and opinions on this. But we talked about what-if the team was truly self-organising, and if there was no hierarchy, could that and would that work. And how it could/would work.

I think we broadly agreed that there was no absolute need for hierarchy and a team could build a situation where there was shared responsibility and accountability (Yes I did manage to inject my favorite 5 dysfunctions of a team discussion to describe how you can build the layers of teamwork necessary to enable this to happen) I would say that we broadly agreed it was possible, but there remained a question of how practical or realistic this was in all cases. 

We generally agreed that the team most of all needed a common goal, they also needed to have a level of competency, self-motivation, the ability to collaborate, and to have trust and respect for each other. We also broadly agreed that continuity of teams was important – teams that stay together longer are generally better, not a universal truth but as relationships are built over time it can be damaging to break up a good team. 

Most people felt there were boundaries for how much empowerment a team could have in a pragmatic context.  Growing teams, difficult personalities, changing products/projects and changing needs which impact team sizes.  We talked about whether you could allow an organization to sort itself into teams and what the implications of this would be, especially in organizations where billing structures are based on team size or it is service driven. 

The conclusion we drew was that a team should not be limited in what they consider possible for improvement, nothing should be off the table. If they believe they are better growing or shrinking or working a 30 hour working week, then any and all are reasonable proposals that a self-organising team could make. But we work in commercial environments and often a larger structure, we do not live in a bubble and for pragmatic reasons we must accept that there will be some boundaries imposed by the organization or indeed by law. But we should be pushing those boundaries and if we are told ‘No’ to something we genuinely believe would improve the team we should push those boundaries and challenge, ask why, and why again.

The Role of the Scrum Master  
   

Does a Scrum Master or team coach fit in this context?  This was a fun one to discuss, if you accept that there is no hierarchy and a Scrum Master is simply a role on team equal to any other, they are just one more specialty skill that a team can organize, they may choose whether they want or need a dedicated SM or shared SM or even need one at all, the same applies for a coach.  However, there were some caveats here, a Scrum Master or Coach has a duality of purpose and whilst they are idealistically organized by the team, they also have an implied independent obligation to coach the team in to independence – and that probably includes independence from the Scrum Master. But again the choice is the team’s.  A good Scrum Master will encourage the team to push boundaries and challenge themselves rather than using the Scrum Master as a crutch.   We had a slight aside here where we discussed how a Coach or Scrum Master can grow emotionally attached to a team or teams and can find it difficult to detach themselves. 

But in a Scrum team that is moving towards self-organization the role of the Scrum Master is clearer, they need to turn their focus away from the team, to step back and enable the team more independence, and create an environment where the team embraces responsibility and accountability, they are not only empowered but are encouraged to explore it.  But at the same time the Scrum Master should turn their attention to the organization and protect the team, push for the team’s decisions to be respected and supported, coach the organization on the merits of empowering the team.  Again this should be a role that lessens as the organization becomes accustomed to a reversal of hierarchy and lessen further when the organization begins to feel the benefit of the team organising itself.
Summary

This was just a few highlights of just one discussion of the day, I managed to attend 6 or 7 discussions or presentations and I may get time to write up some more of my notes in the coming week, but I hope this gives a flavour of the content and of the openness and enthusiasm of the participants and the shared knowledge and experience that was in one place. Companies and individuals sharing ideas and advice.  

I thoroughly enjoyed my day and I’m looking forward to the next event.    

 

 

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.

 

 

 

Scrum at Home – Agile for kids

There was a discussion recently that I participated in where someone asked if you could run Scrum at home for your children. There were a lot of interesting comments and a lot of good observations, generally the consensus was that Scrum was not suitable because most of the tasks for a child are specific to that child. But I shall explore in a bit more detail because I felt that the discussion missed the most crucial question that a coach should always ask.

What problem are you trying to solve?

Now I cannot speak for the people in that discussion so I shall speak based on my own observations and experiences.

Generally in agile we are about finding better ways to give your customer what they really want.  But in the case of Agile for kids the goal isn’t what they produce it is far more about the learning on the journey. I want my children to learn to be self-organising, pro-active, quality conscious, results focused (not done until it is done), to learn to prioritise, to learn to communicate, in some cases cooperation and teamwork.  The tasks/stories are merely tools for that learning.

This is a  variation on the traditional expectation of mastery purpose and autonomy.  If the tasks are household chores then it may be a stretch to hope a teenager will have an implicit desire to master the skill of mowing a lawn, purpose too, may be a hard one to cover on a week to week basis.  Autonomy on the other hand may well be a motivator. There was no real shared vision.

How to motivate?

So if we accept that the motivators that we generally promote don’t apply then we need an alternative.  In my case I chose a reward based system, it feels a little like an easy out, but for my example it worked and this is one area that I would be very keen to hear other ideas.  Kids are difficult to organise, they have a very specific and well honed sense of what is fair – and often it is irrational, this was most definitely an experiment that could go badly wrong.

The constraints and selected framework

I chose a combination of Scrum and KanBan, partly because I know Scrum well but mainly because I felt that the problem lent itself to that solution. The stories would be a combination of household chores and homework tasks.

We chose a 2 week sprint model because most chores have expiry dates and were repetitive, and if I’m honest I took a few liberties with the KanBan board and the tasks.

Mom took on the role of Product Owner, Dad as Scrum Master, and the kids as the team.

We began with a kickoff meeting where we discussed which stories we wanted to be done, this conversation was a mix of the jobs we wanted help with, what we felt the children were capable of and some suggestions from them as to what they felt that they could contribute.  We produced a list of tasks, setting table for dinner, clearing the table and stacking the dishwasher, making beds on a morning, cleaning bedrooms, cleaning other rooms, mowing the lawn etc etc.  Not glamouros but you get the idea. 

For each story we refined it, we discussed a definition of done and we specified acceptance criteria, it was a discussion with all of us: did cleaning a room include dusting, or just tidying and vacuuming?  Taking our the recycling had a specific date, but many of the other tasks had no expiry other than the end of the sprint. 

We then agreed relative size points for the various tasks, one task was fairly easy so got low points another wastime consuming or was undesirable so got more points, we managed to reach an agreement on the relative size of all tasks but agreed that we would re-visit if we felt these were wrong later.

And then on to the reward, we agreed with the kids that we would link pocket money to the board, each story point would equate to an amount of money, pocket money would be paid at the end of the sprint but only and very clearly only for done tasks.  We later modified this to being paid when a card reached the done column, primarily as I wanted to teach the children of the importance of completing stories and of prioritising those nearer to beng done.

With the acceptance criteria agreed we created a board, that had 4 columns (and a separate backlog). Columns were:

ToDo, Doing, Verify and Done.

At the sprint planning we would discuss which tasks the children wanted to take on, and whether they felt they could achieve them all.  Some tasks were clearly specific to one child because of clear ownership or because the task was age or capability specific, but some were joint tasks e.g. cleaning the playroom, and some were for anyone. 

All tasks went in the ToDo column and the kids were encouraged to move cards to doing when they started the task and to verify when they thought they were done. We encouraged them at breakfast to indicate what they would achieve for the day. 

We also encouraged them to write new cards for homework tasks or personal initiatives, although these were not assigned points. Merely to help them visualise their work.

When a card was complete they would move it to Verify and ask the Product owner (Mom) to sign it off, mom would go with them to check against the Acceptance criteria and anything that fell short would be bounced back. I am glossing over the screams of how unfair that was, although perhaps I shouldn’t because of all the things I learnt from this experiment it was how important this particular aspect of it was. Being able to say – “but you agreed this last week” took the wind out of the sails of most of the objections, they still sulked but there was much more acceptance that the parents decision was fair because the rules were agreed with the kids in advance.

So task complete, pocket money paid, happy kids, happy parents, card could be torn up or saved for the next sprint.

At the end of the sprint we reviewed what had been done or not done, and even kept a velocity of sorts. A little competition between the kids. We also held a sort-of retrospective where we discussed what could be improved, although this was a harder concept for the children to understand especially the younger one. We discussed workload, priorities and conflicts – “I did more than my share” some cards were ignored because they felt it wasn’t worth the effort. And so on. 

But we found that the experiment was for the most part a roaring success, the kids even started asking if there were extra jobs they could do.  For joint tasks they used peer pressure to get them all contributing. Rather than having to remind them to do jobs they were reminding us to verify, as I mentioned there was less conflict over what a job entailed.

Problems with the experiment

There were two fundamental problems, the first was the reward mechanism, financial rewards don’t work very well for kids. My 8 year old would see a toy he wanted and when he had completed enough cards for that item, he would stop doing his cards, he didn’t seem to be able to get the concept of saving up for the future. This is something that I think is a reflection of his age, but it made for inconsistent results.

The second was outside interference, at first it was funny but we had a lot of negative feedback, some via the kids. I didn’t understand it, but it was enough to undermine the experiment. The objections were mainly around the reward mechanism.

The third less significant issue was there was a time overhead each sprint and it was not always easy with a busy family schedule to organise this. Although that as always is a question or priorities.

Summary

Overall, I thought it was a great idea, it certainly isn’t Scrum (and I would never claim it was) but it was Scrum-like and the routine worked well for kids. I felt that the kids learnt a lot from it and I certainly learnt a lot. But parenting is hard in general, it is difficult to know whether you are doing the right thing.

I saw them much more self-aware, motivated, it helped communication, and framed boundaries. The kids enjoyed the responsibility and the autonomy. 

But in a lot of ways it was harder for me. As it was a mix of parenting and coaching, I found I needed to overstep my normal bounds of coaching and oddly I felt uncertain of how I should behave.

Ultimately we stopped the experiment, but I still feel it was a valuable learning experience and I would like to repeat it in the future. I would need to re-think the motivation aspect as that was really the weakest part.

However, I would heartily recommend it to anyone with older children, and I’d love to discuss ideas on how better to motivate.

Agile for the real world.

I have once again this weekend been drawn in to reading articles and discussions on LinkedIn, mainly discussing how Scrum=Bad, KanBan=Good, or KanBan=Bad and ScrumBan=Good, and a variety of similar content that frankly is just noise to 99% of the people involved in Agile Software delivery. The reality is that most software professionals really don’t care.

Did I really say that?

It might be a little ironic and I might just be adding more to the noise but I’d just like to bring us down to earth a little.

My experience of Software delivery has been mostly large corporations and the Civil Service, and what I can say with a good deal of confidence is that the staff involved in software delivery want Agile, no question, they are overwhelmingly in favour. I suspect that a step back to Waterfall would see hands go up in horror and a great deal of frustration and maybe even many people leaving in protest.

But I see it as the difference between learning to drive and understanding how an engine works. Most, and that is a sweeping generalisation, but most of the teams I have worked with want me to teach them how to drive, they want to use the skills they learn and to be taught how to teach themselves. What they are not interested in, initially at least, is the mechanics of the car. When they become proficient that may change they may believe that for particular types of driving a different vehicle may be appropriate, but initially simply learning to drive and practicing the basics is as much as is needed and they are happy to have a car suggested to them.

Recently I have been working very closely with three development teams and indirectly with others, and of those teams I’d estimate that maybe 10% have an active interest in the mechanics of Agile Software delivery as a topic and probably less than half of those would give two hoots which flavour of Agile we follow, so long as we follow the principles – most see the framework as a tool like any other it is about getting the job done right. But 100% want to be shown how to use Agile techniques to improve their way of working, but they rely on an expert to guide them. They wouldn’t hesitate to tell me if they thought it wasn’t working.

Most have had no prior Agile experience other than minimal training. Many have been in Agile workplaces in the past but if I am brutally honest they seem to have been poor implementations, a few had good experiences and a very few have been exposed to more than one variation of Agile frameworks.

In the real world a development team wants to build software, perhaps a little over simplistic but a coder wants to code and a tester wants to test. Now I can encourage them to co-locate, cross-skill and try to mix things up, they can use Agile to improve and most have an inherent desire to be Agile and improve. I can show them how to use TDD or BDD, I can encourage them to Pair Program, and they will be enthusiastic and supportive. Most will join in Retrospectives with relish and find true value in Stand-ups, most see the value in Sprint Reviews and the closer engagement with Customers – Why?

Why? Because they are embedded in a framework that works for them, they see positive results and they like what they see. But that doesn’t translate to wanting to have a discussion on the finer points of Agile frameworks. Most don’t see value in a debate on the differences between Scrum and Kanban.

As an example: I have read a lot about #NoEstimates recently and I find it interesting, there are others in my organisation that I could discuss it with and share ideas. But honestly I suspect the teams I work with really don’t care, they use Story Points and T-Shirt sizing because I showed them how and because it works, they see the value. Would they change to NoEstimates – maybe, probably! if I encouraged them to, but the likelihood of the suggestion coming from the teams is low, and it is unlikely to have support or interest of the majority. Certainly not enough of them would have sufficient interest and understanding to make it an inclusive discussion.

However, The same was true of Pair Programming, initially I met quite a bit of resistance from the teams, one guy in particular was very much opposed and resisted, but I encouraged the teams to try it out for a Sprint and then another, and now it is a regular part of their routine and the biggest opponent is now the strongest advocate.

You may be thinking that these teams were not very Agile, or they are not sufficiently mature, but that simply isn’t the case. It just isn’t their primary area of interest. While I am reading about Agile techniques they are reading Tech journals or exploring new tools. As an agile practitioner these details and nuances matter to me, but to a software developer they are just another framework, another tool in their toolkit. The teams may be self-organising but sometimes it needs an outside catalyst to encourage them to push their boundaries.

My point is that software delivery is the goal, the Agile Methodology of choice is just a tool selected to do the job, don’t expect a horde of zealots raising pitchforks and screaming “Scrum”, or “KanBan” any more than they would demand TFS or Jira or any other tool. At least not until they have used it enough to be proficient. That debate is reserved for the agile practitioners.

I have seen Scrum adopted well and adopted poorly, the same with Kanban, neither is a silver bullet, and one is not better than the other (In my opinion). Again in my opinion, when I hear complaints about scrum it is generally because it is not Scrum, but an unchanged organisation that has applied scrum titles, or a cargo cult that follows the schedule without understanding the purpose. And sadly the current trend of handing out certificates to anyone that has done a half-day training course demeans the framework. Too many people see Scrum as a means of control rather than a framework of support, and sadly that is the weak underbelly of Scrum, the framework can be used to create self-organisation but can just as easily be used to stifle it if you have the wrong mindset.

Agile is a mindset much more than a process, the framework is simply scaffolding, but if your mindset is wrong the implementation will be wrong.

I love Scrum, I think it has so much promise and when used well I think it can be hugely effective, in most situations it would still be my starting point with organisations new to Agile, especially when management is not fully engaged. One of the likely intended side-effects of Scrum is that it becomes a tool to regulate the rest of the organisation and create stability for the teams to grow, it creates a protective bubble to enable agility to develop.  

So It saddens me when I see Scrum being seen as a barrier to agility. When ScrumMasters are wolves in sheep’ clothing and simply managers or PMs assuming a title and then undermining the framework, because they don’t understand the essence of the role. Where cargo cults masquerade as agile teams, and when they fail they blame Scrum.

My dad used to say that a “bad workman blames his tools” this was never more true than with Scrum. As a tool in the right hands it can be fantastic, in the wrong hands it becomes a fine quality chisel being used as a crowbar.  

The debate will continue and sadly because of its early success in widespread adoption Scrum has had many poor implementations and so is in danger of bad press which could ultimately spell it’s doom. Far too many experienced agile practitioners are advocating against Scrum based on bad experiences, but I for one believe that as a framework Scrum is good, but sadly there are too many cargo cults giving it a bad name. 

Is Agile a Quantum Leap for a Project Manager?

I have been asked why you can’t have Project Managers in Scrum, and there are a number of discussions on boards that have entertained me, where there is a question about whether there is such a thing as an Agile Project Manager?

The problem for me is that Project Managers are measured on the wrong things, their objectives conflict with Agile goals they are almost always put in a position where they are pressured to conform to a dysfunctional notion.  I see them as a sort of dysfunctional Sam Beckett from Quantum Leap “…striving to put right what once went wrong and hoping each time that..” well you get the picture. There is a notion that the plan in their mind is more important than the reality in front of them.

But in Agile we value “Responding to change over following a plan”

At it’s heart, the job of a Project Manager is to plan a project – usually in fine detail, and then to manage the project to ensure it doesn’t deviate from the plan, and when it does deviate, which of course all but the simplest projects do, the PMs job is to take corrective action to get a project back on plan.  It is about dates, and deadlines and the all-important plan. (cue lightning, harsh shadows and ominous Gantt charts).

All we need is a strangely dressed hologram saying “Ziggy predicts that if we skip all testing of the software there is a 93% chance that we will meet our deadline and the software wont devolve in to a pile of un-maintainable junk for 9 months and 3 days.”

Al_Calavicci_Handlink

The project Manager then gets to ‘Leap’ to a new project without having to stick around to see the mess left behind.

This is in so many ways the very opposite of an Agile philosophy, I see nothing wrong in having a plan, understanding the vision and the goals is crucial. Even some milestones are often beneficial, but the more detail there is in the plan the more waste there is. Everyone including the Project Managers know perfectly well that the plan is flawed, just like every other plan they have ever produced, the difference is that in Agile we accept that the domain is too complex for a fixed and immovable plan. In agile we adjust as new information becomes available, but the traditional Project Manager wrestles with reality and desperately fights to shoehorn a complex reality into a flawed plan.  We all know this, the statistics on ‘failed’ project plans are staggering and yet some still persist in this notion of creating fixed plans and punishing teams for deviating from them.

Agile in contrast focuses on getting the customer what they want, and they do this by getting something to them as early as possible and as often as is practical and then responding and re-evaluating, changing the plan to accommodate the customers evolving requirements. Maximizing value early for the customers benefit.

So can there be an Agile Project Manager? I don’t know, but if the role involves valuing following a plan over responding to change then it becomes an oxymoron.  And with a Product Owner and a Scrum Master I fail to see what useful purpose they can serve in a Scrum framework.

The Mythical Mature Team

On a regular basis I see comments in forums about how in a mature agile team a Scrum Master is not needed, or how the goal of a Scrum Master is to make themselves redundant.

On some level I agree with both comments, but the thing I am curious about is just what proportion of teams are actually mature?

My experience is anecdotal and is obviously reflective of where I have worked and who I have interacted with, but I have worked on Agile projects at 5 major companies, 3 of whom are top 100 companies and 2 major government departments, these are not obscure backstreet companies these are mainstream and in some cases pioneering tech companies. But if you measure Agile maturity on a scale of 1-5 the best would rate a 2/5. They are certainly improving, they are maturing and I am proud to have been part of that process, but they are all a long way from this fabled maturity.

So you might think that the rest of the industry is better and I have just been unlucky – or maybe I am hired because they need a coach to mature.  But again my experience disagrees with this, I do a lot of recruitment: in the last 12 months I have hired 14 developers/testers, and significant numbers at previous clients. I always ask about Scrum to get a feel for their experience and their attitude towards Agile delivery. I must have interviewed hundreds of candidates, and a significant number put that they are certified ScrumMasters on their CV.  But overwhelmingly those that claim to come from companies where they are ‘Agile’ or use ‘Scrum’ – demonstrate what I would describe as immature Agile adoption, sometimes just paying lip service to the concept.

So many, and I mean many! Seem to think that a daily Stand-up means they are Agile, I have had some describe how they are very Agile and follow Scrum closely but go on to describe how the plan is made in advance, a lead engineer estimates and the dev manager individually tasks on a daily basis and that testing occurs in the following Sprint to development and bugfixes are dealt with the sprint after.  I ask about retrospectives and I’d say that maybe 1 in 20 come from teams that hold any retrospectives and those that do describe quite varied experiences.

So for me that mature team remains a myth, something to aspire to.  However, I do notice that over time my role as a an Agile Coach changes drastically, early on a lot of time is spent embedding Scrum Processes, getting the team used to a different way of working, encouraging XP practices, building confidence in the team and showing the value of retrospectives and Agile delivery.  As the team evolves less time is spent on these, as a project progresses there are less impediments, but retrospectives become harder: the low hanging fruit has been dealt with and further improvements require greater insight and more skill to draw them out.  This is not a bad thing and gives time to start pushing out to the rest of the organisation, or taking on a second or third team.

So do you become redundant?  I don’t see it, there will always be some impediments and yes a mature team may learn to solve them by themselves but that is hardly the point, the goal is to allow the dev teams to concentrate on what brings value, and a Scrum Master can deal with many of these problems more efficiently and without distracting the frankly more valuable dev resource.

Also simply by their presence a Scrum Master acts as a counter balance to the Product Owner and the pressure to circumvent the framework.  There seems to be a notion that a mature team is a team of highly skilled software developers and testers that are also interested and eager to enforce Agile principles, and again this is something I don’t see, even the mature teams and experienced agile development teams are not enthusiastic about it in the same way a Scrum Master would be. They understand the value and the importance of Agile, they are wholeheartedly behind it, but that is quite different from the enthusiasm and drive a Scrum Master usually has.

If given the option of completing a task or attending a meeting, many developers would drop the scrum framework in a flash (“just this once”)  or extend a sprint to complete a story (“just this once”). It is also hard to see fault in yourself, and sometimes it takes an observer to reflect your behaviours back at you in a way to enable you to improve.

Metrics can be useful but they can take time and effort to produce effectively, and yes a developer or product owner could do it, but again this is something that a Scrum Master is likely better at and again the developers’ time is more valuable writing code.

Finally, new projects/product increments start and this creates a flurry of impediments, there will be turnover in the team and new staff will need to be hired and integrated into the team, a team may expand or another team needed and all of this runs far smoother with a Scrum Master. When you scale to having multiple teams working together the need for a Scrum Master becomes even greater.

In my opinion, for a new team on a new project a Scrum Master will be very, very busy, but over time as the teams settle and mature I see no reason why a Scrum Master couldn’t support 2 or 3 or in some cases even 4 development teams – assuming they are all located in the same room.

But the prospect of a team or teams without a Scrum Master at all causes me concern as it exposes them to internal and external pressure to compromise Agile principles. And unless there is an enthusiastic team member you are in danger of regressing and whilst you can certainly manage without a Scrum Master, our goal is not to ‘manage’ or ‘get by’ it is to be high performing and efficient.  If the team(s) gets more value from having a Scrum Master than they cost it should not be a difficult choice.

And if you truly want to be Agile, having an expert around to help and to coach would be high on my list of factors that can determine success or failure of a project.

I personally see huge value in having Scrum Masters and Agile Coaches, maybe not 1:1 with teams, but I question your commitment to Agile if you feel you don’t need them at all.

We all still have more to learn, and there are countless opportunities to improve.

One swallow does not a summer make.

Version One  are currently in the process of compiling their 10th State of Agile Survey (Link to Agile Survey)and this caused me to go back and look at the previous results. As an Agile advocate and practitioner I am very pleased to see that last year 94% of organisations say they practice ‘Agile’  albeit that 70% were relatively new to it and could be said to still be in the transition period. This is all great news, it is a sea change and a clear move towards accepting Agile software development as a mainstream way of working.

But, and it is a pretty big ‘but’ how many of these teams are really, truly Agile and how many are jumping on the bandwagon and saying they are Agile when really all they are doing is one or more activity that has its roots in Agile and so ultimately only slavishly adopting Cargo Cult behaviour.

For those not familiar with the term Cargo Cult, it is where some elements of behaviour are mimicked with the expectation of getting the same results, but without really understanding why you are doing it. Cargo Cult    

With many flavours it is difficult to say what makes a team Agile, it is after all an attitude rather than an action, but there are some actions that are generally considered to be core to Agile Principles. At a minimum I would consider: Co-located teams; Iteration reviews; Retrospectives; Continuous integration and Prioritized backlogs as key.  The list goes on but I would struggle to believe a team can be agile without a minimum of those.

So by using my benchmark of what is the minimum less than half 46% (likely even less) do all of those. More than half of those are claiming to be Agile are doing it without co-located teams, without regular reviews, without regular planning, and without regular retrospection. I want to ask them in what way are you Agile?  You could do all of those and still not be Agile, but if you don’t do any then it is doubtful you are able to learn and adapt.

It is with almost despair at times when I am interviewing a candidate and I ask if they have Agile experience, they invariably answer “Oh yes” when I ask them to describe it they will say “well we have a daily stand-up”, sometimes they say more but for a majority that is it.  I don’t hold this against the candidate, most developers when offered a true agile environment learn fast and thrive, but having a daily stand-up does not make you Agile.

The transition to Agile is now in a pretty vulnerable state, the early adopters were motivated and were likely already Agile in nature and the techniques followed on, they succeeded because of their attitude and created a framework on the back of it and for many this works.  The mainstream have heard it works and are mandating a change but are in danger of creating a wave of cargo cult teams paying lip-service to Agile, and when the transition proves difficult they are blaming the framework rather than understanding that it is a change in attitude and a change in culture and not simply a 15 minute standing meeting that must be endured each day.

The message we as Agile practitioners need to get across is that the transition is not always quick and it is very often difficult, but if you adopt an Agile attitude it will pay dividends, if you simply pick and choose one or two ‘Agile’ techniques in isolation without understanding why, you are in danger of failing without ever really trying.