Category: Uncategorized

Rewarding voluntary overtime.

I was chatting to a friend recently, he is a manager of an IT department and I used to manage a software department before I became a Agile Coach so we tend to talk a lot about management techniques and especially how a lot of the successful traditional techniques map to an agile work environment.

It was performance review time and the topic of conversation got around to a frustrating belief by some staff that working long hours without being asked is something that should have an implied reward. That working long hours is in itself a reason to be praised.

clock

Warning signs

I can’t speak for all managers, but for the two of us I can say that we consider it to be the opposite, when someone works late on a regular basis without being asked, we see that as a bad thing, it is a red-flag. Certainly not to be commended and very likely a sign of deeper problems.

I used to pride myself on being a good manager, I felt I was fair and sought to do what was best for my employees and the business, sometimes it was a fine line and often not easy. But one of my strongest principles was to be fair. I would never assign someone more work than I felt they could handle (that is not to say I didn’t seek to challenge them), I would generally discuss in advance what they felt was fair and I would always say very clearly that they should come back to me if they had problems, and I would review on a regular basis – usually at least weekly.

As an Agile Coach I have obviously changed my behaviour a lot and learned so much along the way but generally speaking it could be said that the roles are reversed, the team decide what they feel they can commit to and they review with each other on a regular basis (at the daily stand-up) and can ask if they need help, they should assign themselves small chunks of work and no more than can be reasonably achieved.

Salary man working overtime Overload. Cartoon Illustration.

Have I assigned too much?

In either of these scenarios there should be no scope for voluntary, unpaid, overtime.  In the case of assigned work: if you cannot get it done in the allotted time then it is a failure of my management – either I have incorrectly assessed the amount of work or I have misjudged the individuals capability to do it, and unless I have opportunity to be aware of that I cannot correct my behaviour and the cycle will repeat.

The same is true in Agile, whichever chosen framework you use the model is built on empirical evidence, if your forecasts are off you learn and adjust next time. Working overtime hides problems and perpetuates failing cycles, it also causes an imbalance in the team, it makes pair programming difficult and sends mixed messages to others. Very simply as a team manager or a self-organizing Team you cannot fix a problem you don’t know about.  Overtime is analogous to cards not on the board, it is hiding work, this is very damaging to a self-organising team.

Rewarding bad behaviour

So should you reward someone for working late, for their dedication and loyalty? or should they be reprimanded for their lack of transparency, or their inefficiency of working? Are they displaying a lack of courage in not challenging an unrealistic expectation? Are they stretching work to appear more busy? Should we reward their failure to communicate an excessive workload, or for failing to ask for help with their lack of knowledge/training/understanding to achieve the objective at hand?

As a manager if I ask you to work overtime I would do so with a very heavy heart, I know that it is not good for you, I know it is not good for the business and any gain is short-term and short-lived. It will only be in exceptional circumstances, where there is justification or benefit in working overtime.

As a member of a self-organizing team you should set those same standards for yourself: You should know that it is not good for you or the team, You should know it is not good for the business and any gain is short-lived.

So if you do voluntary overtime which conflicts with our team plans or expectations please don’t expect to be rewarded for it. That may sound harsh but I value communication far more than I value you giving extra time, especially if by doing so it is hiding problems elsewhere that we could and should be addressing.

overtime

Clarification

This is not a call to work to rule, this is a request to understand the difference between being a team player and expecting recognition and reward for setting yourself up as a martyr. By doing so, try to understand that you are working against the interests of the team, this is not behaviour we should be rewarding.

Sometimes it is necessary to work overtime but this should be a deliberate team decision with a clear objective. It should be open and transparent and should not be one person acting alone.

*Note when I saw reward, this is everything from a positive comment from leadership to financial reward. Sometimes leadership even acknowledging this behaviour is seen as a reward, the belief that your actions were noticed is quite an incentive for some.

Isn’t it obvious?

I occasionally get asked why and how I became an Agile Coach and whether it is a fulfilling role. When I began my career I certainly had no intention or expectation to be here, I was a software developer, I loved writing code and like most developers I wanted to create something that made a difference.

What followed was 15 years of… I want to say frustration but that is unfair because I generally loved my work and got to create some great software, but I always had this belief that there was a better way, a more effective way to get the job done, I dabbled in project management and team management believing I could do better than those I had worked for in the past.  My problem and I suspect it is a very common problem is that I spent a lot of effort trying to do my job better, to be more efficient, more effective, to deliver more etc. etc. It turns out that was wrong and I was wasting a lot of effort and not getting the results I expected.

deadly-assumptions

And then quite by accident (and for all the wrong reasons) I stumbled on to Scrum. I was running a software department and we were forever fire-fighting and I saw Scrum as a tool I could use to control the workflow and manage the demands on the team. It worked, and in the breathing room it created I was inspired to look deeper, beyond Scrum to Agile, and then Lean and Systems thinking and the Theory of Constraints and then I saw it. I felt like I had discovered the meaning of the universe, and once you see it you can’t un-see it, you see it everywhere, it feels like it is staring you in the face.

There is nothing more deceptive than an obvious fact. 
― Arthur Conan Doyle

c770ba6b2c578be3db267493229de2dc

Of course I hadn’t discovered anything, I had just opened my eyes and it was right there in front of me and it was so unbelievably obvious that it almost feels stupid writing this.

And it is this simple:

All we have to do is work on the thing that adds the most value and stop working on things that don’t add value.

Work on the thing that adds the most value and stop working on things that don’t add value.

So I said it was simple but it took me 15 years to start to understand it and nearly 10 years later I am still figuring it out, because whilst it is so simple that it should have been obvious all along, it is also remarkably difficult to do.

What is Value?

The primary problem is to understand what value is. figuring out your value stream in a system is key, and to be fair most businesses do this to some extent, but most individuals do not understand how they fit into the system they are in, nor do they understand how their local system fits into the big picture.

We cannot see the value we contribute to the system and when we don’t see what is most valuable, we do what we see as most valuable in our line of sight. Crazy as that sounds it is nearly always the wrong thing, optimizing for us nearly always optimizes against the larger system. The bigger the organisation the more this happens and the more inefficient it gets.

opportunity cost

  • the loss of potential gain from other alternatives when one alternative is chosen.

Another aspect is that so much value is obfuscated, it gets lost in opportunity cost which is invisible on balance sheets and yet is likely the biggest cost you pay when developing software. Or cash flow, leverage and return on investment, these are fundamental aspects of successful business but they are generally encapsulated and decoupled from the parts of the business that can impact them most – especially IT and software product development. Many projects get given budgets and time lines, which is a horrible way to run a business and it cripples cash flow, it also significantly limits investment opportunities and increases risk significantly.  But worst of all it delays delivering value.

Two Problems

So that is actually two problems, first is that we need to figure out what is valuable and then we have to communicate that to those doing the work.

In that sentence is the heart of being an Agile Coach, my role has become one of helping organisations understand their value stream, especially how software impacts and interacts with it, helping visualise that value and prioritise it and then to help communicate that to those that will create the software and deliver that value as quickly as possible.

  • Discover what our goal is – how do we deliver value? What outcome are we trying to achieve? 
  • Communicate that to everyone so we each know how we help to get towards the goal and how we avoid getting in the way.

 

Unfortunately the majority of the time is spent dealing with people that are just like I was, they are doing their very best to be as efficient and possible in their domain, simply because they cannot trace what they are doing to the value delivered.  So I spend much of my time doing my best to help them see that often what they are doing is at best not achieving anything useful and more often is actually damaging to the bigger picture.

Example

victoriaspongecomet

Let me give an example that a friend of mine shared recently:  My friend was baking some cakes for an event and needed to bake 10 cakes, but only had one oven. Her husband offered to help out and so she asked him to measure out the ingredients for the cakes in advance so that it would be quicker to get the next cake in the oven.

When she came to get the ingredients for the cake, they were not ready, her husband had optimised for himself and not for the goal.  He concluded it would be much more efficient for him to measure out 10 batches of flour then 10 of… etc.  after all he knew they would be needed later and it was quicker and far more efficient for him to do that than to do small batches and keep switching.

The result was that whilst he was being efficient for himself, the system grinds to a halt and must wait, his efficiency came at the cost of massive losses to value delivery (cakes baked).

Perhaps if he had understood the full picture, and how his contribution impacted the value stream he would have planned his work differently? He would have prepared one cake at a time even though it was less efficient for him. Together they would have reached the true goal more quickly.

But the funniest part of this story for me was that she was so frustrated,  she thought it was obvious, and he thought he was being efficient.  Those opposing view points are so common in this line of work.

When you see it, it is obvious but until you do it remains an enigma.

Why be a coach?

doc

Now imagine that confusion on an industrial scale, a whole organisation of people conscientiously working hard in the belief they are being efficient but still struggling to deliver software, delivering software that is not what is wanted, features that are not needed, struggling with integration and so on.  Then this loony guy comes in and says that you might actually contribute more by being less efficient.  – I’m the loony guy and I love it.

Agile is a mindset for getting better at delivering software and coaching is about helping you. But my goal is not to help you improve just a part of the system, the goal is to help you improve the system, and that starts by helping you and the whole organisation see the system. and learn how to communicate where we can add value.

Obviously there is a lot more to Agile than communication and value, but in my experience if you figure those out the rest falls in to place.

—————————————

There are a handful of books that I repeatedly recommend, all of which display true Agility and yet to be contrary not one is about ‘Agile’

The Advantage by Patrick Lencioni 

This talks about being clear in your goal and how to communicate it to your organisation, it is not quite as specific as I am hinting at in the article as we must delve deeper but it is an amazing book and the emphasis is on over-communication.

The Goal by Eli Goldratt

This book uses a production plant as a metaphor for delivering value to your customers. The emphasis is on the manufacturing equivalent of delivering working software, doing it regularly, and that delivery is not about development, OR production OR deployment it is about everything – essentially encouraging Dev Ops.  It also has a lot to say about the non-sense of Dev-Done and how the only Done that matters is to have it in your customers’ hands.

Read it!  This is hands down the best book on Agility I have ever read.  There are many others by this author all of which are great but this is my favourite.

The 5-Dysfunctions of a Team by Patrick Lencioni

I wholeheartedly subscribe to the Lencioni school of thought on many things (hence two books by him in this short list). On team building this is one of the best books out there, it describes the stages of team development, and you see this time and time again. Team dynamics are such a crucial part of agility and fundamental to success, this helps teams see those stages and is a great tool for helping teams bond.

 

Mindset or method?

Straw poll:

Should we teach practices and methods in the belief that an Agile mindset will evolve from the good practices?

or

Should we teach an Agile Mindset in the hope that with an Agile Mindset good practices will emerge?

Related image

I know of a few Scrum Masters and a few Agile Coaches in each camp, and some that feel very strongly on this topic. And of course the choice lies at the heart of most Agile Transformations and the outcome will therefore be far reaching.

Method over Mindset

Around 10 or 11 years ago I was introduced to a new way of managing projects and a new software tool for doing it. I was trained in how to use the software, but not in the theory behind the tool.

We are what we repeatedly do. Excellence, then is not an act but a habit.

– Aristotle

The tool was amazing, it really blew my mind. As a Project Management tool/method it made more sense than anything I had used previously and I loved it, I happily used the tool and got good results. But despite having the tool I never learned the theory and didn’t even know where to look to find out more.  No lack of interest or enthusiasm but I was content to use the methods and it helped in my current situation but I was never able to make the leap to more than a method despite my enthusiasm.

It is a little beside the point but the tool was Critical Chain for Project Management and before I was introduced to Agile I thought this was the best option out there for Waterfall projects (probably still is). Sadly despite it being so great, it was still based on the assumption that the end state was known at the start of the project, which for me is the ultimate failure of Waterfall thinking, and my primary reason for moving to Agile.

Only much later did I discover the theory behind the tool was The Theory of Constraints and the 5 focusing steps, IF only I had been shown that and I feel my enlightenment would have come much sooner.  But a method without understanding the theory leaves you unable to adapt and improve, I was limited to the context in which I was shown.

What is more I had a co-worker that struggled with the concept of slack and wanted to follow the method apart from that one aspect – the lack of understanding left him unable to differentiate between a necessary aspect of the method and an arbitrary one, and ultimately for him the tool didn’t work because he rejected the necessity for slack.

A lack of understanding of the theory leaves you unable to differentiate between a necessary aspect of a method and an arbitrary one.

– John Yorke

1cf58fa9895dafded2997558ab348190

Method over Mindset, the Return on Investment

Another consideration is that teaching theory takes considerably longer and has a much lower conversion rate. That is to say that I could teach the Scrum framework fairly quickly – a matter of days, and be pretty confident that the instructions are clear and ‘could’ be followed effectively. To take that same group and to teach them the theory to the point of understanding the why behind each of the practices could take weeks or months, and likely longer before they are fully understood. It is also possible that some will never grasp the theory but are still perfectly capable of being good team players.

Continuous improvement is better than delayed perfection

– Mark Twain

Many organizations are interested in the short-term results rather than long-term understanding and so there is a desire to do the least for the most impact. So we see the evolution of phrases like ‘Scrum-but’ as a means to discourage deviation from the defined framework. Our goal becomes to repeat, rather than understand.

Mindset over Method

cropped-serres-view-4.jpg

If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea!

– Antoine de Saint-Exupéry

The flip side of this is the desire to teach/show the impact of having an Agile Mindset and then having the individuals identify a solution using that knowledge.

Clearly this is a much greater challenge, even those with an Agile Mindset will initially lack any practical applications to draw upon, even the most Agile of mindsets is limited to what they have experienced or read about, and contriving a new bespoke process to your environment may ultimately be the most desirable solution. However, it is impeded by the ability to share that vision and understanding with others, and limited by your understanding, ability and creativity.   And frankly do we really think that we are able to come up with a better framework than Kanban or Scrum on our first pass at an Agile Transformation?

A middle ground?

As you have probably guessed I am not a fan of either approach. I believe that most people will not become Agile overnight and even the most eager of minds will take time to absorb and understand the implications and possibilities of Agile.

I further believe that teaching Scrum as a closed framework that must not ever be deviated from is not the solution. Instead I would compare it to learning any new skill, we teach good practices and when you have mastered them you are ready to move on, we may teach a variety of good practices so you have some comprehension of the possibilities available, that way you do not limit your thinking so just one solution.

But we learn to master the basics, and we learn to question ‘why?’ when we feel we have mastered the basics and we understand why, only then we are in a position to start to evolve.

Applying Lean and XP and Kanban to the Scrum framework can let you grow in understanding within a safe set of guidelines. And when you understand the mindset enough to comprehend the limitations then maybe you are ready to craft your own solution.

If you can’t explain it to a six year old, you don’t understand it yourself.

― Albert Einstein

 

Why I recommend Scrum

Personally I love Scrum as a foundation for a transformation to Agile for those undertaking software development projects, not because I believe it is better than Kanban or other tools, but because to succeed with Kanban you need a level of self-discipline and understanding that is often absent for those new to Agile, and it becomes far to easy to gold plate or run long.

Scrum adds some safety nets and feedback loops that counter many of the usual “human nature” problems that arise from teams new to self-organization. Self-organization is a skill we need to learn and develop like any other. Scrum is so simple to learn, and easy to follow (if you are willing) and once you understand the Agile mindset it is a great framework for evolving into a great Agile team. But like any tool if used inappropriately you can make a mess. But any change requires a good guide.

That being said for support or reactive work Kanban is ideal as the discipline generally comes from outside. It is never a one size fits all.

Leadership

Method without mindset can only take you so far

Teaching the mechanics without teaching the theory is only half the task and whilst it is sufficient for many consultants to get paid, what they leave behind is a culture unable to improve, and without improvement entropy will set in.  I believe both some guidance on the mindset and instruction in some methods are both necessary for a successful Agile Transformation, along with a healthy amount of enthusiasm and patience from those leading the transformation.

 

 

 

Agile thinking in ancient Rome

I found a number of quotes from a popular writer and favourite of Julius Caesar :- Publilius Syrus that I thought were so appropriate to Agile thinking today, it is fascinating how these lessons have existed for millennia and yet we still frequently fail to follow what would seem to be common sense.

RomanSoldier

Here are some of his maxims:

On agility in planning:

“It is a bad plan that cannot be altered.”

 

On commitments:

“Never promise more than you can perform. “

 

On quality:

“Nothing can be done at once hastily and prudently“

 

On multi-tasking:

“To do two things at once is to do neither “

 

2000 years later and the old Maxims are still relevant.

Asynchrony’s First-Ever Internal Conference — Matt Philip’s blog

Among the many exciting things happening at Asynchrony this year, one of my favorites is our first-ever internal conference, coming July 15. I’m a big fan of organizations that take time to learn and share their learning. Especially given that Asynchrony is growing and establishing new offices, it’s vital that we share learning across offices […]

via Asynchrony’s First-Ever Internal Conference — Matt Philip’s blog

Building on the foundations of Joy

I have recently finished reading the book Joy Inc. by Richard Sheridan which is the story of a small software company that has been successful, most notably as being a great place to work. The CEO had come from a an extremely successful start to his career, he had been promoted up the greasy pole to VP of software for an established firm and he had become wealthy in the process. By most conventional accounts he was a success, but he wasn’t happy.  He made a decision to change his work environment with a focus on creating a place that made him happy to come to work. This single minded goal eventually led to the forming of a software company – Menlo – with him as CEO where he could create a place of work that brought him ‘Joy’.

For those familiar with the work of Ayn Rand, I found a great many correlations between Richard Sheridan and Howard Roarke from ‘The Fountainhead’.  Rich Sheridan had a very single minded vision and he chose the path his company would take without compromising on his views. The book portrays how he set the direction and imposed his plan of how things should be done, resulting in a company that has adopted many of the XP practices described by Kent Beck.  The business has been successful and the workers are happy, Pair Programming, short iterations, innovative software solutions and a focus on quality.  The workplace includes dogs and babies and sound like a fun environment. In many respects at first appearance this is a model that we could learn a lot from.

Rich Sheridan has demonstrated the effectiveness of using Agile Practices and that success doesn’t require death marches and unrealistic expectations. Rich has shown one way it can be done, and there is a lot to admire in how he has achieved it. There is certainly a lot to learn and I think there are a great many aspects of what he has done at Menlo that could be used as the foundations of creating a great company.

I don’t build in order to have clients, I have clients in order to build…

Ayn Rand

However, much as I admire Rich and see him as a modern day Howard Roark, it is because of that comparison that I also have a number of reservations.  Rich himself refers to the book “Good to Great” and he acknowledges that he is not a Level 5 leader, this was an assessment I shared whilst reading the book. All his decisions were about creating Joy for himself, but there were dozens of examples in the book of absolutes, where his vision may not be compromised. I got the impression that he made all the decisions, he decided a process and it must be followed, if someone wanted something – such as the wonderful example of babies in the office – they asked him. The decision to allow babies in the office seems to be as much about wanting to be regarded as a great boss as anything else. That is not a bad thing but I am assessing this in terms of a model that can be replicated. 

Rich is uncompromising in his objectivism and Ayn Rand would be proud. Which is only half a compliment, I always admired Howard Roark, for a while he was an inspiration for me, but at some point I realised that taking input from others didn’t automatically mean you were compromising your principles or were weak, we can learn and adapt and improve but still stay faithful to our principles.

Recruitment and single person decision making

His recruitment policy is a great example of what I see as this type of blinkered thinking. Rich has introduced a recruitment policy designed to prevent making mistakes in hiring.  The problem is that his solution is to require two separate interview days, and then a 3-week trial, and after this they make a decision and the vast majority will be unsuccessful.  Anyone else see the flaws in this? 

To get hired you must give up 17 days for one interview. For most people with jobs that is not even close to being possible, and for an good candidate looking they will likely have multiple options open to them and this level of barriers to entry makes it highly unlikely that any good candidate would bother or be able to apply.  Therefore he is limiting his recruitment to the unemployed and graduates that are able to meet his interview requirements.  Now this pool will contain some good (if inexperienced) candidates, but the process has excluded so many other great candidates that I think it is an example of a process that has forgotten what the problem is that it is trying to solve. In this case I assume to hire great employees.

He clearly loves face to face communication and paper based systems and estimation using hours. Therefore everyone must comply, everyone must communicate face to face, they may only use paper based processes and must use hours for estimation. It is not that I am questioning whether the decisions are good or bad, clearly he is getting many right – he wouldn’t be successful otherwise, but it is a company built around a single individual. He is seemingly a strong CEO and charismatic leader, but that leads to an unsustainable business model, where does it leave Menlo when he moves on? What is his succession plan?

Using Agile practices doesn’t make you agile

Menlo use a variety of Agile practices, mostly from XP, but from the way the book describes it they are a set of rules fixed in stone, thou shalt do it this way…

The practices chosen are good practices, but I don’t think that Agile is about using best practices, I think it is about a mindset of improvement. Menlo had adopted a variety of practices that generally I support and endorse, but I didn’t get any sense that there was a culture of reflecting and improvement. Retrospectives did not seem to be part of the accepted practices at Menlo.  This for me was the saddest omission, without retrospectives Agile is weak and ultimately cannot survive in the long run. Menlo seem to have adopted 11 of the 12 principles, but it is the 12th that I value most.

I so wanted to enjoy this book, it is one I had looked forward to reading for a while, but in the end I was left feeling that Menlo was actually on the wrong path. Not that using XP was wrong, but if you have a culture that is not always seeking to improve it will eventually fail. 

I probably sound horribly hubristic, and I have not achieved the level of success Rich Sheridan has, so this may sound hollow.  But Rich, please introduce retrospectives into your culture before it is too late and be prepared to let your teams guide you to improve, you may me amazed to find they have some great ideas. If you do I think you may find a way to improve on the Joy you have already found.  

 

 

 

 

Lies; Damn Lies; and Forecasting…

NoEstimates in a Nutshell

NoEstimates has made a lot of traction over the last few years, with good reason, it is primarily about adopting Agile properly, delivering the valuable work in order of priority and in small chunks, and by doing so eliminating the need for a heavy duty estimation process.  If we are only planning for the next delivery we can reliably forecast.

But sadly that is generally not good enough and some level of forecasting is often requested.  So NoEstimates came up with a very useful and low cost method of forecasting. However, it has brought with it a whole host of misunderstandings, most of which are not from the book. The author must be as frustrated as anyone by the misinterpretation of his proposal.  This has led to resistance from many (including me) to adopting this method for forecasting.  I am all for delivering value quickly and small chunks or prioritized work, but slogans that are used to excuse bad behaviour are damaging and hard to resolve, especially when they seem so simple.

My biggest bugbear and one I have covered previously is that many have interpreted NoEstimates as an excuse to skip story refining entirely, this was not in the book but nevertheless you can see any number of articles on the internet professing how adopting NoEstimates has saved them from wasteful refining meetings, the misconception is that if you don’t need to estimate the story then the act of understanding the story is no longer required.  When actually the author was suggesting that you don’t need to refine all work up front and could defer deeper understanding until it became relevant – the last responsible moment.

planning dilbert

Story Writing and being Estimable

I encourage those writing stories to use the INVEST model for assessing the suitability of a story and in that: the ‘E’ is Estimable,  but that doesn’t mean you must actually estimate the story, just that you ask yourself whether the story is clear enough and well understood enough to estimate if asked – are there open questions? is it clear what the acceptance criteria are and that these can be met?  There may be a subtle distinction there, but NoEstimates does not offer an alternative to writing and refining good stories. It is just a method for simple forecasting and encouraging deferring effort until it is necessary.

How does NoEstimates work?

Caveat aside I will try to give a very high level summary of how NoEstimates forecasting works, and when and where it doesn’t work. I shall do so via the medium of potatoes.

Preparing Dinner

I have a pile of potatoes on the side and I am peeling them ready for a big family dinner.  My wife asks me how much longer will it take me?  By counting how many potatoes I have peeled in the last 5 minutes (10) and by counting the potatoes I still have left to do (30) I can quickly and simply calculate a forecast of 15 minutes.

That is NoEstimates forecasting in a nutshell, it really is that simple.

Assumptions

However, the mathematics requires a certain set of assumptions,

1. I did not apply any sorting criteria to the potatoes I selected- e.g. I wasn’t picking either small or large potatoes, we assume my selection was random or at least consistent with how I will behave in the future.

2. That the team doing the work doesn’t change, if my son were to  take over to finish the job he may very well be faster or slower than me and my forecast would not be useful.

3.  We also assume that I will not get faster

4.  We assume that all potatoes in the backlog will be peeled, and no others will be added. If my wife asks me to peel more potatoes or to do the carrots too, the forecast will no longer apply and will need revising.
So there we have it, a very simple and surprisingly accurate method for forecasting future work.  But do you see any flaws to the system?

Flaws in the system

Flaw 1. Comparing potatoes with potatoes

The first flaw is that I am getting potatoes ready for roasting so I want them to be broadly similar in size, so when I get to peel a potato I am also sometimes slicing it, some potatoes only need peeling others may be sliced once and others more than once.  Some potatoes are bad and I throw them away.

If my wife comes along and sees my pile of potatoes and asks how much longer it will take? I can look at my pile of potatoes I have completed in the last 5 minutes (18)  and I can count the potatoes I still have left to (30). The problem is I don’t know how many unpeeled potatoes were needed to produce those 18 peeled and sliced potatoes, I am not comparing like for like.   To be able to give this estimate I would have needed to count how many unpeeled potatoes I had peeled, information I don’t have.  Maybe I could take a guess and then use that guess to extrapolate a forecast, but that sounds like guesswork rather than forecasting.

Flaw 2. Forecasting an unknown

Let’s assume that I am producing 10 peeled potatoes in 5 minutes, and I am asked to give a forecast as to when I will be done, but so far I have been grabbing a handful of potatoes at a time, peeling them and then going back for more, one could say that my backlog of work is not definitive, We have a whole sack of potatoes but I won’t use them all for this one meal.  I am simply adding work as I need it. My aim being to judge when I am satisfied I am done and start cooking.  It is very difficult for me to judge when the sack will be empty or when I have prepared enough for lunch.

Flaw 3.  Changing and evolving work

It is a big family dinner and uncle Freddie has just called to say he will be coming so we need to add more food, Aunt Florance eats like a bird so probably not worth doing a full portion for her.  And the table isn’t really big enough for everyone, so maybe we should do an early meal for the kids first.  The point here is that simple forecasting only works if you have a reasonably good assessment of what the work is still to be done, if your backlog of work is evolving, work being added or removed then the forecast will be unstable.

Flaw 4.  Assuming consistency

When selecting work to do next I have a tendency to choose the work that will bring me the most value for the least effort.  The highest ROI, so in this case I may choose the small potatoes first, less peeling and less chopping.  But that means that if I count my competed work and use that to forecast my future work I will end up underestimating how much is left, the backlog has some really big awkward shaped potatoes that will take far longer to do. But my forecast is based on only doing small simple potatoes.

Doesn’t this apply to all forms of estimates and forecasts?

Flaws 2 and 3 apply to any form of forecasting, they are not unique to NoEstimates. Flaw 1 and Flaw 4 could potentially be mitigated with the use of T-shirt sizing or story points, but to do so requires a level of upfront effort.  Effort that is not spent on peeling potatoes, so may well be considered waste – that is unless you see value in a more reliable forecast.
For me Flaw 1 is my main objection to NoEstimates (beyond the belief that refining is unnecessary)  When stories are refined and better understood it is normal to split or discard stories, and often add stories as the subject becomes better understood. So any forecasting tool that uses a metric based on counting refined stories to predict a backlog of unrefined stories is risking over simplification of the problem. But because the maths is so simple it can lead to a confidence level that exceeds the quality of the data.  These assumptions based on flawed data gets even worse when you use a tool like Monte Carlo forecasting which applies a further confidence level to the forecast. By giving a date combined with a confidence level adds such a degree of validity and assurance that it is easy to forget that a forecast based on duff data will result in a duff estimate – no matter how prettily we dress it up.

Summary

Forecasting is risky at the best of times, especially in Agile where it is our goal to have the work evolve and change in order to give the customer what they truly want. Forecasting needs to be understood by both parties and accepted that it is an evolving and changing metric. Anyone expecting a forecast to be a commitment or to be static is likely to be disappointed. Just take a look at the weather forecast, the week ahead changes day by day, the further away the forecast the more unreliable it becomes.  Understanding the limits of the forecasting method is crucial, a simple tool like NoEstimates is fantastic IF the assumptions can be satisfied, if they cannot then the forecast will be unreliable.

It is probably also true that your forecast will improve if you spend more effort understanding the work. Time spent refining the stories will improve your knowledge. But no forecast can reliably predict work you do not yet know about.  The question as always is “What problem are you trying to solve by forecasting?” That will guide you in determining whether the up front effort is worth it.
Related articles:

Why I think estimating isn’t waste
Demystifying story point estimation

I do not think that word means what you think it means…

As an Agile Coach I naturally talk about agile practices very frequently, and participate in a variety of discussions with people of varied levels of understanding of agile principles and practices.  But there are certain words that I notice are used with a disproportionate frequency, and used to describe different things. One word in particular gets used very frequently with emphasis and rarely in the right context, that word is Efficiency.  And just for the record, I have been know to misuse it and am making a concerted effort to find the right word for the context, to that end I will try to clarify some of the situations where a different word may be more appropriate.

Efficiency seems to be used to convey such things as. Utilization, Productivity, Effectiveness, Velocity, and sometimes even Efficiency. Naturally I am not suggesting that people are not using English correctly, or that they don’t know what ‘efficiency’ means, but when you look at the examples below you will see that whilst they use the word efficiency in a way that is syntactically correct, they are missing the depth of their question or statement, and often the context. The preoccupation with efficiency results in behaviour that reduces the effectiveness of the team.

For example:

  • Isn’t Pair Programming less efficient than working solo?
  • Isn’t it less efficient to have a developer testing software?
  • Isn’t it inefficient to have the whole team doing story writing (or backlog refining, or stand-up, etc)?
  • Isn’t it inefficient to attend all these meetings, we’d be more productive here?
  • Wouldn’t it be more efficient if I specialize in this one area and all tasks come to me?
  • Wouldn’t we be more efficient and increase our velocity if we ignored technical debt or skipped testing?

I previously covered an example where maximizing utilization of resources was seen as being efficient, but that efficiency was at the expense of the profitability of the business. I think you are missing the point…

In most cases these questions are simply missing the bigger picture, or the larger context.

In KanBan there is a saying that any efficiency improvement on anything other than your primary constraint (your bottleneck) is just an illusion.

If something isn’t on your critical path then it shouldn’t be your focus. Of course as you make improvements to flow and address one constraint the critical path may change, but you should stay focused on the critical path. Identify your constraint and put your efforts there.

Isn’t Pair Programming less efficient than working solo?

The Efficiency of Pair Programming is a recurring question, and one that I likely will not quash here, and that is not my goal. The issue is whether the question of efficiency is the right word, or the right focus for your efforts.

The definition of Efficiency is:  “achieving a goal with the least effort or least waste.” 

Pair Programming assumes two developers at one workstation, and the implication of the question is that more can be achieved with less waste by working independently in parallel.

The problem with Efficiency is understanding what’s it is that you are measuring – what is your goal, and identifying whether this particular activity is your constraint in achieving that goal.

Let us take a car journey as a very simple example: What is the most efficient journey?  Is it driving at 50mph so as to use less fuel? Is it to get to the destination in the shortest time to reduce utilization of the vehicle, or could it be driving in the middle of the night when the roads are clear and the vehicle is not needed by anyone else?

In all of those examples we are focused solely on the individual journey itself and even then we still have ambiguity of which efficiency we are concerned with.  But very likely the reality in that situation the destination is just a step towards the goal. That isolated Driving journey is unlikely to be entire goal in itself – unless maybe I am a taxi driver, and even then I suspect my constraint is maximizing fares rather than reducing costs, so likely maximizing the number of fares rather than driving efficiently is my goal. Driving efficiently only at 4 am may not be the ideal business model.

The road less travelled…

If for now we assume that we are driving efficiently to use less fuel, because fuel is expensive and money is more of a constraint than our time. Then possibly the most efficient journey would be to combine multiple journeys into one (car sharing, or batch delivery), or make a phone call, in this context a journey not taken(or shared), is far more efficient than the most efficient journey.

I glossed over that fairly quickly, so take a moment to think about it. Efficiently doing an unnecessary task is just waste.

Efficiently doing an unnecessary task is just waste.

Time = Money

But hold on, the most efficient journey for me could simply be one that gets me to my destination on time, regardless of cost or duration. My time and the appointment are more important than the cost efficiency of the journey.  Sure I would prefer the journey to be shorter and cost less if that can be achieved without impacting on my goal, but my priority is being there at a particular time. A super efficient journey that gets me to my destination 10 minutes early so I can sit idle for 10 minutes does not help me to my goal, the efficiency gain is just an illusion.

For a while I used to car share, and it saved me quite a lot of money, but I was tied to a schedule and my journey was much longer. After a while I realized my constraint was time and not money. The ability to be flexible over my schedule was a much bigger constraint. My journey became more expensive but I needed flexibility to reach my goal. In other words efficiency in one area may not just be an illusion it may actually cost you more elsewhere as a consequence.

This is a far too common situation in business, a business will often go on an efficiency drive and look to cut costs without any consideration to the larger impact that the efficiency savings are causing. The focus becomes narrow and they delude themselves and often others that they are being efficient, when actually the true constraint is ignored.  The cost cutting creates larger costs elsewhere.

Why? What is the goal?

I don’t mean to labour the point, but to be able to understand efficiency we must first understand the true goal, and it is very likely that the true efficiency we are interested in is related to a goal at a higher level.

Let us revisit the Pair Programming.  Our goal in programming is to deliver a software solution, likely a quality solution that meets the client’s needs, with minimal support requirements. It is likely that they are also interested in maximizing return on investment.  So where does the issue of efficiency for programmers come in?

Pair Programming as an activity shares and grows knowledge, it often enables more creative solutions, the quality is higher, there is an inherent in built code review and QA in to the process. So the question isn’t so much whether Pair Programming is more or less efficient in terms of number of lines of code written; or stories coded; or bugs found; but whether it is producing a better return on investment overall in the context of our true goal: in terms of quality, support and meeting the client’s needs.

I don’t plan on answering the question to the satisfaction of the skeptics but I suspect my opinion is fairly evident.  My point is not to directly answer the question, the point is that the real issue is not what it first appears to be when the question was broached.

If your team is dealing with support issues, bugs, deployment problems, getting features to customers quickly and so on. Then it is possible that ‘coding time’ is not your primary constraint.

In this case the response to the question of efficiency is:  What are you measuring to determine efficiency? Or…   Is efficiency of one singular part of the process our primary goal or is it just an illusion? Would being more efficient help you to be more effective at achieving your goal?

Summary

In this example the word efficiency is taken in a context to justify behaviour that possibly diminishes the effectiveness of the team.  Lean principles do look to minimize waste and to be more efficient, but lean looks at the end to end flow and is only concerned with efficiencies when it is applied to the critical path or a bottleneck and ONLY when those efficiencies are removing waste in the context of our overall goal, not simply a small part of the flow.

If we improve efficiency at a point before a bottleneck all we do is pile up work faster, if we improve efficiency after a bottleneck or anywhere not on the critical path we fail to see the benefit because the flow is already limited by an earlier bottleneck, there is no net gain to our efforts. Our efforts are just an illusion.

As a very generalised statement we as individuals find it inconceivable! (Had to include it somewhere) to view our work as part of a larger scope, our desire to be efficient in our own little bubble often leads us to behaviour that is inefficient for the larger scope that we are part of.  We should be less concerned with being efficient in our roles and more concerned with doing what is effective for the larger system or team we are part of.

Efficiency is not the same as being Effective

Prefer being Effective over being Efficient. Make sure you are effective at achieving the goal first and foremost before even looking at efficiency, and then only if increasing efficiency does not come at the expense of being effective.

Visualising our work in that larger scope is one of the best ways of understanding where we are struggling to be effective and to highlight where the true efficiencies can be gained.  But try to see the whole process not just your part of it.

 

 

 

 

I think you are missing the point…

A brief story….

A team found that many of their impediments and problems with delivery were caused by a lack of access to IT operations or lack of responsiveness, they requested a member of the IT operations team be co-located with (and become part of) the delivery team. This was approved and trialled as an experiment.

From the perspective of the development team this was a major success, delivery times improved, delays were reduced and the major constraint to delivery was aleiviated. In short software projects were delivered sooner and with less complications, the overall cost of delivery went down dramatically.

However, the management team decided to remove the IT ops team member and retrurn them to their old team on the basis that they were not being fully utilized.  The notion of a human resource not being fully utilized was too much for them to bear.

[Please note when I say utilization – that is on IT Ops tasks – they were using ‘slack time’ to support the team in other ways]

When I challenged this decision, I was told that they were unable to increase headcount for IT operations staff unless it could be demonstrated that existing resources were more than 100% utilized on IT Ops tasks over the course of a normal week.  So anyone not 100% utilized was considered a problem for them and became a burden on other team members.

This same IT operations group has a huge backlog of work and lead times were extremely long, they were a major bottleneck for almost every aspect of the business operations.  Sadly the management team did not see any correlation between the absence of slack time and the long lead times.

Too often the dependency on IT Operations and their perceived hindrance to business operations, leads to unnecessary conflicts and frustrations. Usually felt by the staff on the IT Ops teams. But it is because IT Operations are so important that they get this reputation.

How can you justify extra resource if you are not fully utilizing the ones you have?

I have no doubt this is a common story, “how can you justify extra resource if you are not fully utilizing the ones you have?”  In principle this would appear to be a perfectly reasonable and logical statement, and I can understand why many management teams fall into this trap. But it is the wrong question.

What troubled me most was that we had demonstrated that the impact and delays suffered by the delivery team in just this one example were actually costing the organization so much that they could easily pay for 5 or more additional IT operations staff with the benefits gained. And more so that this situation could be repeated all over the business.   The response from the IT Ops manager was that I was missing the point, and they couldn’t justify underutilizing staff.  Their measure for success was maximizing utilization of staff, and not supporting business goals, like say profitability.

I see this mainly as a failure of the business, for not making clear to management where they contribute and how they impact on the larger business objectives. That combined with a manager that either doesn’t see or doesn’t challenge this omission leads to perpetuation of dysfunctional behaviour.

Managing resources effectively not efficiently

I apologize for comparing people to resources, but in this context it is applicable.

Could you imagine if that same principle was applied to other resources?  Your PC would be taken away if you didn’t use it 40 hours a week, you would be forced sell your car because my guess is that you only use it 10% of the time. You would wear the same clothes every day.  Cooking would be a nightmare if you could only have food where all ingredients took exactly the same amount of prep time and cooking time.  I’m getting silly now but it is the same principle, by totally ignoring the reason why we have a resource and focusing entirely on maximizing it’s utilization we behave in really rather perverse and contrary ways.

In any other context the notion that anything less than 100% utilization prohibits buying a second item (regardless of how beneficial) is plain nuts.

Please do not misunderstand, I am not encouraging waste by this, I am encouraging understanding of how resources are being used. When you are meeting the business goals and your flow is optimized, that is the time to look at whether reducing waste is possible but to do so in a way that ensures that any reduction in waste is not hurting business goals.  It may turn out that just like your car, the optimum utilization is less than 100% and availability and responsiveness are valued higher than utilisation.


Summary

In this situation, I am very proud to be “missing the point” and I wish far more managers would take the time to understand how their role impacts the larger business and perhaps they too will miss the point and start asking important questions. IT Operations in particular are the lifeblood of so many businesses and their actions can make or break a business, understanding all the areas of the business that IT operations supports and how the cost of delay is often significantly higher than the individual cost to operations of that task or that ‘resource’.  The ability for IT operations to prioritize and  react promptly to the needs of a business is a far better measurement than measuring utilization of staff.

I’d highly recommend that anyone in IT Operations reads the book The Phoenix Project by Gene Kim, and ensure that anyone that benefits from the service they provide also read it.

Understanding how you contribute to the goals of the business is so important, and if after that you truly believe that your role should be maximizing the utilization of resources and not supporting the business achieve it’s goals, then I would suggest it may be you that is missing the point.

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.