Agile and Lean Management @scrumprouk - Tumblr Blog

Lean Leadership Principles

Lean Leadership principles

What can Agile teams learn from the German World Cup champions?

(Cross posted from Medium)

After a month of binge-watching football let the hangover begin.

The runners-up match the day before — between Holland and Brazil to determine who finishes in 3rd place — can only serve to separate the truly addicted from the merely interested. I devoured that game like I had the previous 62.. but ask me today who came third in 2010. I can’t tell you and I’ll probably forget at some point that Holland came third this year

I was happy to see Germany win against Argentina in the final — I have some German friends, a European team has never triumphed in South America and this is the first win as a unified country. When the Germans last won in 1990 it was as West Germany in a divided nation.

So Glückwünsche Germany… you deserve to be world champions.

During the week the Evening Standard in London published an article examining the German squad and the ingredients to their success.

I’ve linked to the article here in full resolution. I found the newspaper on an Underground train and took it home to scan the article. Immediately I could see lessons to learn for my teams at work.

What can Agile teams learn from the World Cup champions?

Organise, organise, organise

Perhaps the over-riding Germanic characteristic — the football squad was fantastically organised.

Agile teams can learn from this — Agile is not a byword for anarchy and Agile is not an excuse not to plan or not to organise. There are many opportunities to do this in an Agile squad, from the cadence of regular ceremonies to the hygiene of the product backlog and the presentation of the team board. Be organised.

Always prepare

I believe the German team won because of their formation, discipline and routine. They didn’t have a single standout player like a Messi or Neymar or *cough* Rooney.

The German team were well prepared as should your Agile team be.

Teams reach a level of high performance once routines that add value become ingrained into the team — like a muscle memory.

Pair programming, writing testable code and accompanying automated tests. Good communication. These things don’t happen, they are practices that need to be taught, honed and integrated until they are routine.

Be direct

My favourite! I’ve bought copies of Patrick M. Lencioni’s book The 5 dysfunctions of a team for the teams that I work with and I encourage everyone to read it.

It describes high performance teams and the absence of traits that could kill high performance. For example — if a team has Absence of trust that leads to Invulnerability. The presence of Invulnerability leads to Fear of conflict.

You can see the model below but please run… don’t walk… and buy that book for your team.

The German team certainly had no absence of trust or fear of conflict from what I saw throughout the tournament. When a team has a clear focus and purpose it’s easier to pull together and call out behaviour that is detrimental to achieving the objective.

Work as a team

For me this is the most telling attribute of the German team. I’d heard of only a few German players before but they won because the sum of their power and skill was greater than the 11 component parts.

Does your team perform as a whole better than the sum of the individual efforts?

Act clinically

The Evening Standard introduced the German word for ruthlessness (Unbarmherzigkeit) which I’d use more often if enunciation wasn’t such an issue! :-)

This unbarmherzigkeit is what lead to a 7-1 demolition of hosts Brazil in the semi-finals and I’d like to see my team be more ruthless… in the right way.

The reason that my team switched from abstract story points to cycle time (elapsed time from starting a feature until it’s acceptance) is that we can be more ruthless in the elimination of wasteful activity.

Moving from “We complete 20 points in a sprint” with the associated opportunities to fluff and pad and alter estimates to our current system of “Our cycle time for features is 6 days” exposes wasteful activity. It gives the team a chance to be predictable, have a target to aim for and to be ruthless in its execution.

Be disciplined

To keep this article short.. lets roll up all of the above under the heading “Be disciplined.” I think it works anyway.

Teams should be organised in their artefacts (stories, backlogs, team boards) and in their practices (design, build, test, deploy).

Teams should discover which practices work for them and incorporate them into their working agreements and daily routine. By regularly practicing good practice simply becomes muscle memory.

Teams should have a shared purpose and objective and should be comfortable enough with each other to highlight negative behaviour without it becoming personal or vindictive.

Teams should be ruthless in their execution. Train hard and execute well now when the pressure is off and you’ll execute well when it’s a week from the end of the release and you need to make late changes.

All of the above takes discipline from the team, from the ScrumMaster, Agile Coach and management team.

And lastly…

BE HUMBLE

Doing well in the previous sprint is no guarantee that you’ll do well this time around.

Team performance suffers hugely through atrophy and you have to actively keep improving through introspection.. even to keep performance level.

Be humble and always on the lookout for ways to improve. Retrospectives help.

In summary…

So the World Cup is over and so are my hopes that England can put together a decent team for 2018.

During the next 4 years I’ll be concentrating on applying the learnings from this years World Champions to the Agile teams that I work with.

I hope you do too!

Wireframes on the teams board

How do you know you have team that embraces self improvement?

I spent the last few days in our Amsterdam office with some others, including one of my ScrumMasters. Naturally we kept in contact with the team by attending the morning standup over Google+ Hangouts and via email and IM.

During that time the team finished one story and picked up the next. Whilst planning the story in detail a mini-retrospective was held, although they weren't scheduled to have one until Friday.

And the team - in our absence - fundamentally improved how they visualised their work.

We've used wireframes in the past - Balsamiq is our preferred tool - and as much as possible we make them visually available to the team.

Wireframing is great. It provokes conversations and debates about the approach we are taking to solving a problem. Having a standup conversation around a whiteboard with a wireframe pinned to it leads to an open, engaged, physically active discussion.

The same people huddled around a computer screen leads to a closed off, quiet conversation, often without a well understood outcome.

So what did the team do whilst their manager and ScrumMaster were away? They agreed that in the previous story not everyone was engaged with the solution and were working away on their small piece of technology.

Writing technical tasks on cards and progressing them through the "TO-DO", "DOING" and "DONE" columns wasn't giving everyone all the answers to the questions they had. It was an abstract way of describing the work that needed to be done.

For this story the team stuck all of their tasks to the wireframe itself. "Configure this field to constrain it's choices". Previously an abstract task and now it is cognitively associated to a place on the wireframe.

You can see tasks that have faces stuck on them - they've been assigned and work being removed from the wireframe and placed in the Done column.

As one team member said this morning "For the first time I don't have any questions about this feature"

What was my role in this improvement? Getting the hell out of the way and providing a working environment where the team feel safe in experimenting and implementing their own improvements.

I genuinely wish that this was my idea to suggest. But of course the guys and girls that are closest to the work have the answers to the problem: Genchi Genbutsu

#Kaizen

How to read cumulative flow diagrams

Love the concept of wall skills - one page printable graphics on technology subjects.

Here is how to read a cumulative flow chart

#kanban

The ingredients of Kanban

I enjoyed this infographic on the ingredients of Kanban

#kanban

Regular Agile team surveys to gauge morale

A short while ago we took the opportunity to change the structure of our little corner of the development organisation.

We based our new structure on the Scaling Agile @ Spotify whitepaper which I still believe is one of the most promising and exciting examples of making Agile work across a large organisation.

So far - we've had moderate success. Cross-functional team members are organised into squads and we have 2 tribes in different locations. The formation and curation of guilds is harder and we are still working on that.

One interesting example from Spotify is the use of surveys to find out which kind of organisational support is needed from the teams either in terms of additional coaching, tools or process support.

This week we'll send out our first developer survey. I think this will be helpful - although squads hold retrospectives each iteration it's hard to get a broad view of how people feel. The retrospective - quite rightly - should go deep into some subjects to uncover issues experienced in that iteration. There isn't always time to ask questions over a broad section of topics.

Here are the questions that we'll send to developers - I would love some feedback from other organisations that have done similar exercises.

The questions are grouped into the following sections

My vision and purpose

Product Ownership

Process that fits the squad

Quality and testing

Morale

Organisational Support

Summary questions

Each question will be presented with a sliding scale of answers

Never

Rarely

Occasionally

Often

Very Often

Always

(Cleverly avoiding an odd number of questions - otherwise people hit the middle option without thinking)

My vision and purpose 1. I know both the short term goal that my squad is working towards and the overall release objectives for the AppDev organization. 2. I know how to view the Product Backlog and which backlog items are most important 3. I start work each day knowing what is expected of me Product Ownership 4. The decisions I make relating to product development are aided by feedback from real customers 5. The stories I work on are well defined and have clear acceptance criteria 6. The team (including my line manager and product managers) have the right balance between speed and quality Process that fits the squad 7. The SDLC process is effective in getting the work done rather than simply being a process that must be followed 8. I am an active participant in my teams process and growth and my voice is heard during retrospectives 9. My team has a learning culture and we are making active, regular improvements both to our technical competence and our process Quality and testing 10. Our automated test suites allow me to make changes to the product quickly and safely 11. The team is passionate about quality and our actions result in a high quality product 12. The amount of time invested in maintaining quality is proportionate Morale 13. I work at a sustainable pace - not so fast that I make mistakes or so slow that I feel underutilized. 14. I am a member of team that is working towards a common goal and with individual agendas 15. I enjoy being a member of my squad Organisational support 16. My physical office environment allows me to be productive and work closely with my team 17. Managers outside my Agile squad are available to help resolve technical or organizational issues that we cannot control ourselves 18. My team is generally well supported in terms of tooling and process. Summary questions 19. The team is effective and productive as it could be 20. Being a member of this squad gives me an opportunity to progress and grow in my role 21. I see the value in this survey in order to understand how the team sees their work

I'll be sure to write about the outcome of our first developer survey.

As a leader, which mode are you in today?

Recently I've been thinking a lot about leadership. Reading Turn the ship around by L. David Marquet has been transformational for me. There are also some great thoughts in Notes to a Software Team Leader by Roy Osherove.

When it comes to leading people there are fundamentally two choices of style with a distant third.

The Command and Control "dictator" model.... "Do it my way"

Empowerment style.... "Do it your way"

Lean Management.... "Follow me and we'll figure it out together"

John Shook defines these styles well in a conference keynote a few years ago

"Empowerment" isn't a viable option IMO

I would disregard "Empowerment style" as a choice of leadership strategy despite the Agile methodology being seemingly aligned to this model.

I don't think it's feasible to bring people together, provide a vision and just walk away expecting great results. Teams need a more active style of leadership than that.

As much as I want to believe that every software development team will be completely self-organising, self-determining and autonomous I'm yet to see it in action.

For me self-organising teams have a specific meaning around the habitual identification and solving of problems and implementing improvements via systematic learning rather than operating autonomously without leadership

So we are left with "Command and Control" and "Lean" as two viable options for leaders to adopt.

Every Agile and Lean book you'll read will tell you that "Command and Control" is a bad style of leadership. It stifles real engagement from participants, encourages a hierarchy where information flows into a bottleneck and removes the workers from the responsibility for their work.

However - I suggest that there is a place for this technique in a leaderships skillset. In fact I'm encouraging my two squad leaders to constantly evaluate whether the time is right for this style of leadership to be engaged.

Which mode is your team in today?

The job of a leader is to constantly evaluate the situation that the team is in and to select a mode of leadership.

On any normal day the team should be in Learning mode meaning that they have enough slack in the system to learn from their work.

That should involve implementing ideas from previous retrospectives or experimenting around TDD or pairing. In this mode the team should self-organise around their work and remove the need for the team leader to actively lead.

In this mode the team leader is a true servant-leader, coaching, removing impediments and facilitating the team.

A practical example of a team in Learning mode would be the morning standup. Too often standups are all about the ScrumMaster being front and center. Ever seen that happen? The ceremony turns into a reporting exercise with information flowing from the team member to the ScrumMaster.

In learning mode I'd go as far to say that the ScrumMaster should be physically 6 feet behind the rest of the team listening in to coach where necessary.

And when the s**t hits the fan...

The idea of "slack time" is important to this concept. The team leader should be aware when the team has no slack time in which to run in "learning mode".

Slack time can evaporate for a number of reasons - urgent customer issues, outages, unexpected critical work, the team slipping against a deadline.

Lean management requires slack time as a critical component in order to learn and implement kaizen improvements.

When slack time evaporates the dynamic of the team should change into Survival mode. The team leader needs to take a more active leadership approach and demonstrate more command-and-control characteristics. Perhaps being the dispatch controller, tracking work centrally and guiding team members from task to task.

I still believe that true self-organising teams are a wonderful aspiration and should be worked towards.

But pragmatically the idea of leaders that can deploy an effective leadership style when it's necessary is a great balance between Lean management and command-and-control.

#leadership

Agile estimating in a Scrumban context

Last night I went to the London Kanban Coaching Exchange to listen to a talk by Nader Talai titled "Does size matter". In his talk Nader told us a story of a team that gained trust with its stakeholders through improved estimation.

Our journey with Agile estimation...

Personally I have been through an Agile estimation journey with my team over the last year. In our work before last August my team ran a fairly vanilla Scrum routine, meeting three times a sprint for an hour to discuss and size the top of the backlog.

For us, at that time, estimation was a useful practice and we felt we were accurate enough. Taking work that we'd recently completed and comparing upcoming work against it; asking "is upcoming feature X bigger or smaller than completed feature Y" gave us a good sense of what we could take on.

At that time, during sprint planning we'd take our targeted stories and plan in detail assigning an estimate of hours against each task. To be fair - we were often wildly inaccurate at estimating the hourly tasks but it all held together and we enjoyed good trust with our stakeholders.

Moving from Scrum to Kanban...

In August we made a few changes. Firstly we started working on new projects for new stakeholders. Secondly I had read a lot of debate about #NoEstimates and wanted to remove a lot of the overhead associated with estimating - especially estimating tasks in hours where we were failing to improve. Lastly - for business reasons - it made sense for us to become very familiar with the mechanics of Kanban rather than Scrum.

So between August and January we shifted our routine to Kanban. I blogged a fair amount about our experiences if you missed it and we felt fairly successful in that transition. Certainly we felt predictable in our delivery even though we'd stopped estimating work in either story points or hours.

Additionally, by tracking the cycle time of each user story we had a good basis for Kaizen - identifying the elapsed time from accepting the work to it being completed and where work had stopped in the process.

We were able to point to our cumulative flow chart and say with confidence "By the end of the release we'll be here" or "Based on our previous data the next feature will be delivered in 12 days (with 80% certainty)". Those probabilistic predictions felt a lot more stable than using abstract points to project into the future.

But we lost something by not estimating work...

At the moment we are planning our next release which will run over a number of months. The business drivers for using a strict Kanban methodology have changed so we have some free reign to adopt our process.

In our release retrospective recently we agreed that striving for continuous flow and moving away from iteration goals meant we lost some valuable interactions in the team.

Some members missed the focus that a sprint goal and commitment and the two week timebox gave them.

Others missed the planning and estimating meetings where they had the opportunity to discuss and get a shared understanding of the work. For them the practice of estimating was more valuable than the outcome of the estimating session.

The evils of estimation

Last nights talk by Nader crystallised some thoughts for me. When we moved away from Agile estimates in our last release we realised the value of cycle time and the Lean method of identifying waste in our process.

Holding up a "13 point estimate" as the only measurement of size abstracts a lot of evils that might lurk in the teams work.

Firstly if teams feel under pressure to meet a certain velocity (lets say 26 points a sprint) it's too easy to buckle and start to play with the numbers.

"OK, lets take this feature and call it 13 points even though last time we called it an 8. We need to keep our velocity up"

"We're 2 days away from the end of the sprint, lets make sure we get this feature done quickly to keep our velocity up"

Neither of these patterns are helpful. By making the work bigger you mask a lot of inefficiencies that will follow. If the developer can actually complete the work faster because he over-estimated to make the velocity report look good will he gold-plate the feature to use up the remaining time? If the team finish early and bring in more work does that make the velocity chart more accurate? Of course not.

By rushing to complete work before the end of the sprint, normally an arbitrary date anyway, only quality can suffer. Why rush to complete a feature in order to satisfy the velocity chart if you have to then rework it later or ship it with low quality.

How about this one from the Product Owner

"You can do 26 points in a sprint right? So I can trade these two 13 point features for twenty-six 1 point features??"

Of course not.

How we are going to use estimates

Despite the above I believe estimates to be helpful. They only go bad when the output is used as a management tool and especially when that management exists outside of the team.

Here is how we are going to use estimates in the next release.

Use story points as a planning guide but use cycle time for predictability, reporting and kaizen Estimating in T-Shirt size or story points is a useful activity because it encourages conversations about features and promotes shared understanding of what is complex (big). It also identifies features which are candidates for decomposition so they can flow easily through the process. To track predictability cycle time (how long a feature takes to complete) is a much more powerful metric. It provides a guarantee to stakeholders with an accompanying range ("We can provide a feature in 12 days (with 80% predictability)" and that is backed up with concrete data.

Always remember that the value in estimating is the activity, not the output Taking time to estimate throughout the release promotes discussion and highlights where team members have different interpretations of the requirements. If one member estimates a feature at 1 point and another member at 13 points... you've just realised the value of estimates. That misunderstanding needs to be straightened out before development starts.

Don't drive the team to get better at estimating Mike Cohn has the following model in his book "Agile Estimating and Planning"

I like it - it shows that the accuracy of estimates increases dramatically with some low amount of effort but will never reach 100% accuracy. And actually trying to improve the accuracy of estimates requires significantly more effort and actually ends up reducing accuracy as you gather more and more data.

Teams will continue to be inaccurate in their estimates - thats fine and expected. Your predictability and trust with stakeholders should be built using probabilistic data (cycle time and cumulative flow) leaving estimates to be a team activity and metric.

Thanks Nader for a thought provoking talk

#Estimating

What CustDev is and is not

Last week I wrote about a Customer Development methodology that we are codifying in my organisation.

We are a group of product development teams in a larger, established company. Although we don't have the problem that "The Lean Startup" and "The 4 steps to the Epiphany" aim to solve (who are our customers, which market are we entering?) we do have a need to validate our product vision amongst our existing known customers.

That word "vision" is important.

Customer Development is not a methodology for interviewing customers, discovering their biggest wishes, complaints or issues and building a product roadmap. It is also not a process for holding focus groups and getting feedback on completed features.

From our companies inception we've been led by visionaries and a product vision that is simply the sum of a list of customer wishes would not have taken us to our market position today. We feel that we have to lead our customers to innovative solutions at a rate that is slightly faster than comfortable for them.

The "Technology Adoption Lifecycle" model is useful.

We feel that our job is to satisfy our existing customers across the market but to innovate and predict which products will appeal to the Early Adopters and Early Majority, keeping everyone moving to the left across this diagram.

#custdev

A new Lean Customer Development methodology

Currently my teams are in the period between product releases, tidying up on the one just gone and planning for the one ahead. It's a great time to think about Customer Development and how to apply it to our next product iteration.

I'm a huge fan of books like "The Lean Startup" by Eric Ries and "Running Lean" by Ash Mauyra and "The 4 steps to the epiphany" by Steve Blank.

These books hold a wealth of generally applicable techniques and guidance but solve an adjacent problem.

They all deal with the problem of "We have a vision for a product.. is there a market fit and what should the product actually be". They deal with the uncertainty of customer discovery (do they exist, will they pay for a product) and product validation (is this idea for the product the right one).

Fundamentally they deal with business model planning and validation.

In my line of work I have to solve a slightly different problem. I work for a Platform-as-a-Service company. My customers are known to me (I've been talking to them today!) and my motivation isn't to discover if a market exists or which pricing plan would appeal to which market segment.

PaaS and SaaS economics

The PaaS and SaaS economy is driven by a few key metrics:

New customers: Bringing people into the system that weren't using the product previously

Renewals: Keeping those customers happy and using the product

Upsells: Expanding the product further into the customers organisation to increase the numbers of users

The aim of Customer Development for me is to build a product that will drive one (or all three) of those metrics for my company.

I'm struggling with what to call this methodology - it isn't the same as Customer Development as codified by Steve Blank, or Lean Startup as codified by Eric Ries.

This is a methodology in need of a name!

What is Customer Development

In my organisation Customer Development exists as a methodology in parallel with Product Development (Agile, Scrum).

As a methodology it complements and reinforces Product Development by eliminating risk, uncertainty and the causes of rework and waste.

What are the aims of Customer Development

The aims of Customer Development, in order, are:

Systematically prepare the Product Development teams to build a product that will drive new customers to our product (new logos) and will drive customer loyalty (renewals).

To reduce waste in our Product Development process by building the “right thing” first time.

To shorten the feedback loop between developers and customers.

What are the principles of Customer Development

There are no facts inside our building, only opinions. Facts come from validated research with customers.

We aren’t interested in building what we think is “the right product”. We are interested in building a product our customers will use driving new logos and renewals

The biggest source of waste in Product Development is feedback delay. Customer Development provides feedback on assumptions, ideas and features as quickly as possible to eliminate waste.

Lots more to come on #CustDev and our work to build a product that will drive logos, renewals and upsells!

#custdev

Finding the 1%: The danger of atrophy in Agile teams

According to Wikipedia.....

Atrophy is the partial or complete wasting away of a part of the body. Causes of atrophy include mutations, poor nourishment, poor circulation, loss of hormonal support, loss of nerve supply to the target organ

"Agile team atrophy" is something that I've experienced with teams before. Left over time there is a potential for good habits to drop off and bad habits creep in.

Standups might be skipped if we're all too busy today. We don't have time to write an automated test for that feature. We don't need a retrospective for this sprint.

My team seems to march over rolling terrain - walking up steep inclines towards great agile practices but sometimes wandering through long valleys where things start to slip and require attention.

I read a great post by James Clear on BufferApps blog - by the way, one of my favourite internet companies at the moment after hearing Joel speak at the London LeanStartup group.

James wrote about the science of marginal gains. What happens if you improve everything by 1%

Follow @james_clear // <![CDATA[ !function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+'://platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,fjs);}}(document, 'script', 'twitter-wjs'); // ]]>

From James' post:

It’s so easy to overestimate the importance of one defining moment and underestimate the value of making better decisions on a daily basis.

Almost every habit that you have — good or bad — is the result of many small decisions over time.

And yet, how easily we forget this when we want to make a change.

So often we convince ourselves that change is only meaningful if there is some large, visible outcome associated with it. Whether it is losing weight, building a business, traveling the world or any other goal, we often put pressure on ourselves to make some earth-shattering improvement that everyone will talk about.

Meanwhile, improving by just 1 percent isn’t notable (and sometimes it isn’t evennoticeable). But it can be just as meaningful, especially in the long run.

And from what I can tell, this pattern works the same way in reverse. (An aggregation of marginal losses, in other words.) If you find yourself stuck with bad habits or poor results, it’s usually not because something happened overnight. It’s the sum of many small choices — a 1 percent decline here and there — that eventually leads to a problem.

I believe in this model. In fact I'd go further in the application of the model to Agile teams and say that if you aren't continually improving by 1% you are probably regressing somewhere. Teams need to keep improving.. most of all to keep the idea of Kaizen alive.

If you have a learning culture built into the team and the ability to experiment it's possible (but not easy) to regularly find that 1% improvement and make it stick.

Without that culture of improvement (Kaizen) even if you think you are standing still you are very likely to be regressing by 1% week over week.

What improvements have you made today? Answers in the comments please!

#kaizen

Size versus complexity versus delivery time

I've been repeating a theme recently on this blog and twitter.

Feature complexity and size don't correlate to time to build. Using Cycle Time and Story Points to Improve as a Team http://t.co/rc61WHb8dm

— Simon Morris (@Simo_Morris)

February 2, 2014

"The size of a work item or it’s complexity has no correlation on the time it takes to deliver the work." #Kanban http://t.co/o0HQFoGqFl

— Simon Morris (@Simo_Morris)

January 28, 2014

I believe this to be true - if you stop measuring purely dev time and start to measure the end-to-end value stream from requirements analysis, feature definition, planning, dev, test, documentation and polishing time.. variability naturally reduces.

And don't forget the wait time between each activity. In my team the cycle time is outrageous and there is a huge amount of time wasted whilst features sit between activities.

Here is the scary thing - even if you go and find a couple of amazing developers with great productivity will you ship sooner? Eliminating waste in the form of wait time has to be the primary focus for Development Managers.

Some additional confirmation from Kirk Bryde in the kanbandev mailing list

For a large release for a Fortune 500 organization of about 1,500 stories over a 9 month schedule (and about 30 teams) I compared the CFDs [Cumulative Flow Diagrams] for story-points vs. story-counts, and the curves looked almost identical. i.e. There was no discernable difference between the shape of the curves when these "right-sized" stories were counted individually (when the y-axis was story-counts), or when the y-axis was story-points. (The organization used Scrum, so they liked to use story-points, but my CFD comparisons proved that it really wasn't necessary - counts of the stories proved to be just as accurate.)

To Paul's point, it is amazing how much some teams (and leaders) will fret over poker-planning (story-point estimating) and metrics-tracking of story-points - without sufficient added value to justify the time taken. At the end of a large release, there are so many OTHER factors that cause MORE variability to delivering the software product "on time", so precise story-point estimating and tracking doesn't really matter.

#Estimating

"Limit Work In Progress" versus "Fix it on sight"

Email to my team.

Hey team,

After chatting with Asad this morning I wanted to send this note to explain my thoughts on "Limit WIP" versus "Fix it on sight".

I was explaining a change that we need to make and said that he shouldn't focus on that right now, we'll give it priority in the backlog. Asad pondered for a moment and said "But it's a one line change"

Here are my thoughts. Limiting WIP is crucial for us in order to get things done. If we focus on a small batch of changes at one time we get work completed faster and with higher quality. It is really easy for us to start a lot of development changes and explode our WIP levels. Doing that means that we have untested, undocumented and unknown code in the system which would suck.

BUT!! You guys are all a lot closer to the solution than I am. If you see issues that are truly "fix it on sight" issues please go ahead and whack them. I would define a "fix it on sight" issue as something that a pair can complete dev and testing on in a single timebox. (What is that? An hour or two? An afternoon??)

Just make sure that if you start a "fix it on sight" it doesn't require resources that aren't currently involved (Documentation would be a good example) and that you do actually finish it within the time box you set.

If you defer quick fixes because I told you to backlog it, you are letting process get in the way of progress when it should be enabling it.

Feel free to tell me "I can complete this quickly, I'm doing it", I won't have a problem with that.

You guys are a self-organising team, I'm here to coach and if I'm telling you something that you feel is wrong just let me know.

18 days to go!!

#WIP

Kanban work items - to slice or not to slice

As we draw to the end of one large project - only 21 coding days left to go, people - we already have one eye on our next adventure. We're thinking about how to improve predictability and quality in our next release.

This was our first experience using Kanban to deliver a large software project and we've been happy with the outcome. It was also our first time not estimating the size of features using "planning poker" and relying on probabilistic data collected from completed work.

A conversation on David Andersons "Modern Management Methods" Yahoo! group has helped me understand how to improve our process.

A wrong assumption that I had made was that we should strive to break all work items down to be roughly the same size. According to David this is a common bias that folks from the Agile world bring with them to their Kanban thinking.

Scrum == Deterministic, Kanban == Probabilistic

We're stuck on the idea that we can be deterministic by estimating work - either by assigning story points to the work items, or by attempting to break them down to be equal size. Both activities attempt to control and understand the size of the work involved.

Kanban offers an alternative approach - using data gathered from past work we can be probabilistic about how long work items will take. The idea that we can control the work by estimating or attempting to split into "the right size" is neither helpful to the process or impactful on the time it takes to deliver the feature.

This is one thing we know to be true after our current release and the cycle time measurements that we took:

"The size of a work item or it's complexity has no correlation on the time it takes to deliver the work."

Unless you work in a very high efficiency environment there is actually little need to control the size of work items. The likelihood that size correlates to lead time is unlikely.

I think this is a common misunderstanding - Davids blue book on Kanban does mention "reducing variability". After reading the mailing list I went back to the book and I see that it's a long way down the list of efficiencies that could be implemented.

Teams coming from Scrum may believe that Kanban requires small, consistently sized work items to be effective. It seems that this just isn't true.

Handling variability efficiently is a competitive advantage

One of the main benefits that we've taken from using Kanban as our method of controlling work is the ability to handle urgent requests and bug fixes.

Our team handles customer support issues, urgent bug fixes and feature work and Scrum didn't gracefully handle the interruptions that kept happening.

In a high efficiency environment reducing variability in the size of work items might be a benefit. In most development teams they should look at their ability to gracefully handle interrupts and different types of work as a competitive advantage.

As someone said on the mailing list: Let the water flow around the rocks gracefully. Don't try and control the rocks too much.

Use classes of service to handle variability

Our Kanban system allows for different classes of service to be applied to different types of work items. We allocate 20% of effort to fixing problems and 40% each to our two products that we are enhancing.

Classes of Service is the right method to control variability rather than splitting work down to be the "right size". Classes of service control queuing discipline - how soon work will be started after being added to the queue.

Treating types of work (note not different sizes of work) with different classes of service allows you to make decisions based on probabilistic data.

This is much more helpful than trying to be deterministic by using story point sizing or splitting work into the same size chunks

My conclusion?

In the next release we'll still split features into work items but I've moved away from the idea that all items need to be the same size.

The data we've collected from our current release gives us a good understanding of how long features take and size and complexity are attributes that don't directly affect the delivery time.

#estimating

The beauty of small batch sizes

I blogged last week about code reviews with the awesome Phabricator. The team is still impressed with how it's working and how code review has changed.

From an experience where you might get a code review if you are lucky (or unlucky) to where you know that you will consistently be reviewed. It's great stuff.

Individual members of the team are now pitching in on reviews. Phabricator allows individuals to define rules that create audit tasks based on author, keywords and so on.

It struck me whilst reading some code today that systematic code review reinforces the Agile and Lean principles of controlling batch size.

Working with small batch sizes gives faster feedback

When someone is asked to give a review on an entire feature they might be presented with dozens of files and hundreds of lines of code. Realistically how good a job can they do?

By minimising batch size you give the reviewer a chance to analyse your changes in a decent amount of detail. The effectiveness of the review increases.

Small batch sizes and systematic code review tools like Phab, also means that you get feedback much faster. This is hugely valuable in decreasing the overhead of context switching - the productivity killer.

If you write enough code to formulate a useful batch of code, commit and push it, I'll get a code review task assigned. I can get back to you within minutes due to the small batch size and you can incorporate that feedback quickly. Rather than rediscovering the work you had submitted.

Working with small batches localises problems

Committing small batches of code means that problems introduced can be found, isolated and fixed sooner. Much better than sifting through a lot of code that somehow worked locally but now results in dozens of failing tests.

Small batches decreases overhead

This seems counter-intuitive but I really believe it to be true. By encouraging smaller batches of work to be committed we obviously increase the number of code review tasks that are needed.

But each code review task is easier to understand, feedback flows back to the developers quicker and quality improves. Resulting in less concerns raised back to the team and better code overall.

If an activity that is deemed critical to the team seems to have high overhead the best way to tackle that is "do lots of that thing". Efficiencies are found because people are incentivised to find them and the system improves radically.

Eric Ries - the Lean Startup guy - has a great blog post on working in small batches sizes

#quality

A week in code review with Phabricator

My development team has used code reviews as a tool to control quality for a long time. We've always been aware that peer review is an effective tool to find bugs early but - honestly - we've been going the motions with it for a while.

We would include "Peer review" on our kanban board as a task and that would get done, but then additional work and polish would happen, and more code would get pushed into our repository.

Our team had a commitment to code review but no system. A change this week has turned code review on it's head and I feel had a massive impact on our quality.

We found Phabricator - a Free Software product built at Facebook that offers a suite of tools for development teams. Its has issue tracking and collaboration features that overlap with our own tooling but they can be stripped out to leave a really nice code auditing tool.

We now have an easy-to-use systematic way of reviewing each and every commit.

Phabricator can either host your code repository or in our case we've configured it to pull from our centrally hosted Git server.

A rule is setup to create an audit task if any of the team push code - both I and my senior developer get asked to audit code but anyone can jump in and offer a review.

The audit task sits there in my queue. The interface for reviewing code is just great.

You can see some code that one of the team wrote - perfectly good code but with a second pair of eyes you can see a possible future bug.

The method this._secureRecord returns either a database record or null if something goes wrong.

The code works great but line 69 calls .update() on that record - that won't work if the value is null and we could check to make sure.

Phabricator sends off an email and then tracks the concern until the team resolve it.

Code review is by far the cheapest way of finding bugs and we've shortened the feedback cycle for our developers by giving code reviews that are targeted.

Give Phabricator a go for your development team!

#quality

Moving on from ServiceNow

Today, after 2 years, 4 months and 2 days - considered to be some length of time - I handed in my notice at ServiceNow.

I don't have much juicy gossip - it's an amazing product, a great company and a hugely talented group of individuals. Maybe in the future I'll do a more critical review of my time there but, as a spoiler, it would be overwhelmingly positive with some commentary about the challenges of a hyper-growth company and a development organisation that nearly tripled in size.

If you are a customer considering the platform - buy it. They are on a trajectory that will kill SFDC in 5 years. They've already served BMC their breakfast in most prospective accounts they go in to.

If you have a chance to work there - do it. It's an incredibly hard working place but there are still a ton of challenges to solve.

So why did I leave? Well - firstly, I don't have another job to go to just yet which probably says something.

My most-used retrospective technique with teams was "The Organisational Soup". A technique for classifying challenges and problems by the teams ability to change them.

From FutureWorks consulting.

All individuals face challenges at work - their boss, their projects, their environments. To tackle challenges it helps to write them down and place them on the above chart.

What challenges can you as an individual exert control over? What challenges can you influence? What else is there that you cannot either control or influence? Well - that's where I've been struggling.

These factors exist in "The Soup". You can't control or influence some people or some circumstances and so you can only respond to them.

I felt strongly enough about some of the challenges that I faced to take a response action of moving on. It's all good, I can't wait for the next challenge.

There are some amazing companies to work for out there. Who's next!?

#unemployment

Trending Blogs

Recently Viewed Blogs

Agile and Lean Management