This cautionary tale came up a few times at Agile 2010 (yes I know this may be old news!) – including one of the keynote speeches.
“For a million dollars we’ll make you Agile.
Here’s a list of previous clients whom we helped achieve a 1,000% performance improvement. Lead times halved, profits doubled and everyone was AWESOME!.
Here’s some REAL DATA …”
Axis titles shamelessly acquired from a recent company presentation
What you’ve not been told is that those testimonies are statistical outliers!
These are the top 1-5% of companies that have successfully undergone a major transformation. (or the bar was set very low to start with) There are thousands of companies out there that don’t reach these lofty heights.
The journey is longer and harder than the marketing will ever tell you but that’s fine as long as you know what you’re investing in and why.
Your organization is unique. There are many factors about your organization that will make significant improvements hard to achieve and most of them will not be technical. The forces of resistance will be many and will be a mix of institutionalized and personal.
Let’s replay this with a more realistic conversation…
A consultant visits your site, and does a “free” one-day Agile Assessment of your teams.
“OK Boss. Right now you suck at developing software. Give us a million dollars, a year of your time and a willingness to drop productivity for a while and we can make you suck a bit less.”
Furthermore, they won’t actually be able to tell you just how much less you can suck and by when.
Back to all those forces of resistance – how many of those can you really prod, assess and quantify in a day or even a week?
Every company, organization and site differs.
The investment may still be worthwhile but it’s time to manage expectations better. Those assessments should highlight where unexpected limitations lie. Maybe they could offer alternative higher priority areas to tackle (rather than up-selling scope).
If product development and software engineering was like cutting coke cans, there really would be a “one true right way” of producing software products.
Moreover. There wouldn’t be a thousand consultancies promising you the moon on a stick, there wouldn’t be conferences on improving the state of the art and there wouldn’t be hundreds of books full of great ideas on how to do/be agile or perform software engineering a little bit better.
In fact chances are there wouldn’t be a competitive software industry.
Or would there?
• Maybe there really is a one true way and the entire software, consulting, authoring and conference industry is in on the joke.
• Maybe all those leading lights on their skiing trip a decade ago came up with one of the world’s greatest “Long Cons”
• Oh and they invited 3M to the party and agreed to promote stickies in the 21st century in exchange for a marketing budget.
There are no “best practices”. Stop looking for them, stop asking consultants and Scrum Masters to implement them.
There are only “best known practices for your current state, knowledge and context”.
When your state, knowledge and context change, it’s time to look at what’s next and more importantly – what’s beyond your current focus – what have you missed or not considered yet?
What did you discard previously because there were constraints or issues preventing them working? (I learned a great term for this from Chris Matts &/or Dan North – I can’t remember which – “Idea Wombling” – seeking out great ideas that were previously discarded)
You may reach a point where your organizational immune system (politics and process) blocks progress.
Sometimes you’ll need outside help to see what’s “better” or learn new ways of working. That outside help can often be more effective at delivering hard truths than you can yourself. It’s worth investing in “straight-talk” from strangers sometimes.
Figure out what is holding larger improvements back (and where) and determine who you could pair with either externally or in a different part of the organization to make a real difference!
Back in December last year I started supporting Red Gate’s .NET Developer Tools Division. As of this month, we’ve restructured the company and from next week, the old division will be no more (although the team are still in place in their new home).
When I joined the team things were going OK but they had the potential to be so much more so I paired up with Dom their project manager and we set to work.
The ANTS Performance Profiler 8.0 project was well under way already and the team had a basic Scrum-like process in place (without retrospectives), a simple whiteboard and a wall for sharing the “big picture”.
I spent the first week on the team simply getting to know everyone, how things worked and observing the board, the standups and the team activities.
We learned some time ago here at Red Gate that when you ask a team to talk you through their whiteboard, they tell the story of their overall process and how it works. Our whiteboards capture a huge amount about what we do and how we do it.
I attempted to document and capture at least some key parts of the journey we’ve have over the year in which we released over a dozen large product updates across our whole suite of tools. This post is picture heavy with quite limited narrative but I hope you’ll enjoy the process voyeurism 🙂 If there’s any specifics you have questions about, please ask and I’ll expand.
Next time, I think I’ll get a fixed camera and take daily photos!
The end result? Multiple releases of all 5 of our .NET tools including a startup and quality overhaul for our 2 most popular products, support for a bunch of new database platforms, full VS2013 support (before VS2013 was publicly released), Windows 8 and 8.1 compatibility and a huge boost for the morale of the team. See for yourself if you’re interested!
Of course this is just one aspect of what I’ve been up to. You might notice the time between photos over the summer grew a little. See my last post for more insights into what happens at Red Gate Towers.
If you aim to improve, inspect and adapt on a frequent basis in a highly unconstrained way, stick to a whiteboard (as large as possible) and stickies (and possibly scissors, tape, card, paper, pens – did I mention that many Agile coaches I’ve met have an addiction to stationary that stems back to their childhood :)).Your process will adapt to the project significantly faster with a manual board.
As an example, here’s the original board used on my current project (it’s now cleared down as we migrated to a better space) :
(Thanks to Andrzej for the rather disturbing portrait)
The board was too small and constrained (much like many electronic tools) so we switched to something better. We reused the board layout and approach from a previous project (see 5S your Scrum board) as a kick-start but less than a week later we had already moved forward significantly from where we’d started. Our needs on this project were different enough that we had to adapt.
Here’s what the current board looks like this week:
(Thanks to Ellie for the donated parrot)
The mass of stickies across the bottom of the board is where we cut scope for this sprint as the result of an over-commitment. This was spotted as soon as we migrated to this board and I started plotting additional information for the team around the edges.
Admittedly what we have here could potentially be implemented electronically as a board and a series of “widgets” but that needs development skills and time – this would slow down our speed of adapting.
In our example, adding avatars was a 15 minute job with scissors & tape, adding a capacity planning check took 2 minutes and adding new charts and graphs took 10 minutes. Better still – an unplanned adjustment – when we have a success story from our users, one of the team will bring the evidence along and tag it to the board in whatever format they wish.
There’s some further changes needed to our process this week. One of the horizontal streams of work is a (roughly) repetitive series of activities so we’re going to start tracking cycle time on these and moving to a Kanban model as we need to start setting expectations to our users for these areas. In parallel, the less predictable work will be continuing Scrum-style for the development team. We’ll be ensuring the board captures these stats for us to see every day.
As soon as you start using electronic tools, there’s an immediate speed barrier to the changes you want to make plus there’s often the constraint of a small screen (or investment in a large one), how to add related information in meaningful ways without underlying data model support, user experience, data entry and the ability for non-technical team members (my current team is 50% sales & marketing staff) to make changes.
Don’t get me wrong, when you have a globally distributed team, you’ll almost certainly need an electronic tool as a single point of truth but it’s just not tactile or flexible enough to support the level of interaction and adjustment that a constantly evolving project and process needs. Many companies adopting electronic tools push for standardisation to keep processes consistent, costs under control and sustain support for reporting aggregation. This really stifles making adjustments to the process to suit project and environment context.
I’m not entirely down on electronic tools. I’m actually quite a fan of Trello at the moment and use this for sharing our bigger picture with the spectrum of stakeholders we have around the business that cannot be co-located. At least it’s a tool aimed at users, (rather than many commercial electronic boards whose capabilities tend to target management reporting instead) however for now Trello is limited to swimlanes, a constrained card format and the need for a screen. It’s not quite tactile or ubiquitous enough. Extending it requires time, technical skills and screen real estate rather than simply a process gap and a creative team member.
In my time at a very large US corporation we did a great job with the constraints we had. We used giant smart boards with virtual card walls, high-spec videoconferencing and large TV screens. At the time it really was state-of-the-art stuff but it still limited our visual management capabilities. We only ever really had a shared basic card wall (the reporting and metrics weren’t particularly visible to the teams). All the other peripheral information you can get from a great board during your standups wasn’t visible.
The teams actually developed and maintained physical boards in each location and ended up using the electronic tools as a synchronization point.
Whilst we could virtually move cards around on a giant touch-screen, changing information on the cards themselves required reverting to a keyboard, detaching from ongoing conversations and manually editing within the tracking tool. It worked but it really was a compromise.
Contrast this to our current board – if something needs adding or updating, the active conversation continues whilst a team member grabs a pen and starts writing. If our process changes, we update the board format the same day.
I just had a passing chat with my colleague David (another of our DevOps team) about electronic vs physical boards. He summed it up brilliantly; “I don’t know why… …but it’s just not the same”.
We also tailed off into the value of an entirely co-located team. A rarity for many these days but a real game-changer in the performance of your teams – I’ll cover this another day.
So in summary, even where you have distributed teams, work with a physical board for as long as possible to allow your processes to adapt and develop to the context and project around you. When you start using electronic tools you’ll find the pace of process improvement will significantly decrease.
I’m a big fan of Goldratt’s Theory of Constraints for getting important improvements made in the most suitable order for a team. Our current scrum board is the result of focusing on the most evident, soluble problem each day for a couple of weeks. No grand plan, just good emergent design.
Note this is a very long article as some readers of part 1 asked for all the details as soon as I could get them written, today’s the first time I’ve been near my blog in a week. I’ll switch back to shorter posts after this for a while.
Here’s an in depth look at each of the areas of our board…
Using the peripheral space for useful stuff
A single sticky with a quote regarding some feedback. The last 3 sprints we’ve left one up there that says “It shouldn’t be all that hard” . A reminder not to generalize (“it” was much harder)
One sticky. Our current theme is “Contact Management”, The next will be “Dashboarding” or similar. Just a little reminder of what the overall focus of the sprint or sprints is. This helps when clarifying or controlling scope, questions, debt & defects.
During sprint planning we look at who’s in, when and what other commitments they have (beyond the usual overheads and maintenance activity). Capacity is calculated in half-day (4-hour) increments for each of us, totalled up as a whole team in hours. We then subtract 40% for overheads & support.
We track a second capacity number under the first which is the actual total effort hours of tasks completed in the last sprint. Generally this is a fair bit lower than the forecast.
The differences between these two figures are useful input for understanding our capabilities & overheads.
We limit tasks during sprint planning to around 70% of our maximum delivery capacity or close to our previous delivery capability in order to leave space for unknown / discovered activities and hurdles. If planning another story would take us over this level, we hold off until we’ve actually been able to deliver the first – there’s no point in breaking stories down into tasks if they’re highly unlikely to happen in the next 2 weeks.
If we really do well, we can always reconvene.
At the moment we have 2 sets of tags on the board; “Blocked” and “Please Test”. The team no longer uses the “please test” tags so they’re likely to be removed this week. We assume coding tasks include developer-led testing activity and any other testing is planned in as scheduled tasks. This has reduced dev-test handover as the whole team focuses on the set of tasks required to complete a story, not their individual tasks.
I’m likely to add “red tags” soon for tasks that need particular focus or expediting. We’ll limit the use of red tags to one WIP item at a time and only when needed.
A color key for our tasks. Currently we have
blue : code & test
green : design & ux
yellow : test
orange : management noise
pink : support & bugs
The top horizontal swimlane of our board contains stories and story activities. The left-most column of this contains story cards in priority order from top to bottom for stories planned for this sprint. The space here is deliberately small. The last 2 sprints we had only 2 stories listed, in the next sprint we’re actually reducing it to 1 and having the whole team pull single stories through. (Update – We ended up pulling single stories as a flow after this point right to the end of the project)
A placeholder for “extra” stories.
If we really do clear all the stories on the board, this area is a placeholder in rough priority order for the next 1 or 2 stories we might play. These are not broken down into tasks unless there’s certainty that we’ll actually work on them in this sprint.
A more traditional lean technique. We have an individual holder for 1-2 pads of each color of stickies. We can quickly see if any are running low and replenish stock. We also have a holder for story cards although that’s rarely used (we generally don’t add stories when stood at the board).
There’s also a holder for pens. We ensure there’s enough marker pens in the holder for everyone to have one during our standup and we ensure that there’s one of each whiteboard pen color needed for drawing graphs and totals on the board.
Hours (on stories)
This is the initial estimate in effort hours of all tasks we identified prior to & during sprint planning that went onto the board at the start of the sprint. We compare these with total hours completed at the end of the sprint to learn from and improve our tasking and estimation.
Over time we hope to gather enough data to see the typical ranges of hours spent on stories of each size (we expect a bit of overlap)
Our second main horizontal swimlane is “sprint tasks”. These are all the activities required by us as a team in order to be able to complete the sprint and usually deploy our working software to production. We also tend to add extra technical debt cleanup items into this swimlane.
This approach seems better at the moment than having specific (and artificial) stories for these activities.
It’s up to us how much trade-off we have between sprint tasks and story tasks in a sprint. Since creating this swimlane we’re finding 40-60% of our effort is going into this area however this is because we’ve been prioritising some technical debt and deployment improvement activities. That rate will adjust over the next couple of sprints.
The bottom swimlane on our board is for support issues and bugs. Right now we’re not using this very much as our support and old bug fixing activity has been relatively low.
We’ll see how useful this lane is longer-term.
Note, bugs related to work we’re actually doing are either fixed immediately and not added to the board at all or are added into the stories swimlane relevant to the story they’re found in.
Todo, WIP and Done are the typical status lanes for tasks you see on most boards these days. “Next” is an addition we added in very early on and has been a bit of a game-changer in managing the flow of tasks effectively here’s a link to the full article on the “next” column.
I talked a little bit about this at the UK Agile Coaches Gathering this weekend and I’ll expand more in a standalone article shortly. Put simply, we found that getting potential retrospective input visible every day during the daily standup has been more effective in driving continuous improvement and makes it easier to collate retrospective data at the end of the sprint. Mike Pearce also recommended something similar over the weekend – maintain your release and sprint timeline with pitfalls and lessons so that there’s less head-scratching at the end.
We’re tracking burn-down of task hours for both sprint tasks and story tasks in parallel (different colors). Then on the same graph we’re also tracking the burn-up of total capacity. It’s working okay for us at the moment but I can’t help thinking it’s still not quite right so I’m sure we’ll revisit this.
Beneath the burn-up/down we’re tracking per-sprint velocity as a basic bar chart. Straightforward, simple, easy to complete and easy to understand.
Sprint Schedule / Countdown boxes
As of the end of the last sprint we removed the sprint schedule, the list of historic dates wasn’t adding anything for us. We have the current sprint dates at the top-left of the board instead and have used this space for a set of countdown blocks 10..1 with effort hours to do and forecast remaining each day. This gives us immediate feedback as to whether we may have a problem in meeting the end of the sprint with current task scope. I’ll write up the experience on the countdown boxes separately once we’ve been using them a while.
This serves a couple of subtle purposes…
There’s something very satisfying about taking tasks from the board and dumping them in the “done done” box.
We clear down the board into “done done” at the end of each sprint. This makes it clear that we’re not really done until we’ve completed everything and cleared the decks.
Although the box itself is basically a trash holder, it serves as a constant reminder that we’re not done until we’re done 🙂
We’ve added a few more things since I drew the original picture of our board…
After the daily stand up we sum up the total effort hours for each horizontal/vertical swimlane square/block and scribble those on the board. We can then transpose these into tracking graphs.
Right now we only track todo by horizontal lane and overall done but we have the data available for cumulative flow tracking if we feel the need.
We’ve added a very small space for newly accumulated or discovered debt related to our current work. It’s deliberately small to keep things minimal. When it fills up we’ll need to do something with it (if not sooner). It gives us one more line of slack if things go unexpectedly in a sprint for some reason whilst we still focus on deploying working software. This is still a running experiment but the intention is to treat this like credit card debt – it’s a short-term postponement mechanism, not a backlog.
Next Sprint Tasks
In much the same way as we have “extra” stories, we’ve added a placeholder for tasks we need to do in the following sprint but don’t have capacity for right now. This stops us overloading the current sprint tasks lane once things start moving without forgetting important future activities.
An Update (November 2013)
I’ve been rooting through my old photos and found a picture of the board toward the end of the project (September 2012) so you can see what it *actually* looked like as it evolved beyond what I’ve described above.
Don’t be afraid to adjust your working area if things don’t seem to be flowing right.
This isn’t the end for our board adjustments, what we’re using will certainly be different in a few weeks time however today it serves our needs well and must remain simple enough for new team members to understand.
I strongly recommend reading Henrik Kniberg’s recent book. I read the review draft last week (July 2011) and saw close similarities in the board structures the PUST teams at RPS were using and what we have here. I also share the same view as Henrik that each team – even within the same group – should be free to choose their own board style.
Try taking a few of these ideas away to experiment with but you probably won’t need them all.
Some weeks ago I joined a new team. I don’t like causing disruption but I do like to get the pace of improvement going on my teams. Here’s how we started out together…
During my first week I observed my new team’s activities. They were trying hard and doing pretty well but hitting some hurdles. Their most obvious challenge was the impact of covering support activities and cleanup tasks in addition to new story delivery.
Other than the loss of expected delivery capacity, this unplanned work was causing problems during stand-ups. The flow and continuity of useful conversation was being lost as the team stopped to hunt around for the right coloured super-stickies, a working marker pen and figuring out where to put the tasks. (but… they were aiming to get these tasks visible!)
Borrowing some 5S tricks from Lean, I started work…
Seiri (Sort); eliminate all unnecessary tools, parts, and instructions.
Seiton (Straighten); a place for everything and everything in its place.
Seiso (Shine); clean the workspace, and keep it clean.
Shitsuke (Sustain); don’t revert to old ways, continue looking for better.
I skipped Seiketsu (Standardize).
Each team I’m working with is establishing their own natural, effective way of working within a common framework. I don’t believe seeking further standardization is something that will help them right now. (Although I’ll be setting up a community of practice for sharing successful and failed ideas shortly).
We added a small new change to our board, stand-up and/or tracking every day over a week – generally this involved scissors, tape, markers and old cereal boxes!
We reviewed & cemented the successes and added a couple of bigger changes during our retrospective.
Here’s the current result. – I’ll post a photo in future (I’m writing this at home on the weekend).
Using the peripheral space for useful stuff
Clearing the decks, having specific right-sized places for consumables (colored sticky pads pens, story cards) and swim lanes for support items & cleanup tasks solved a number of problems quickly…
The support/new work split is clearly visible and we’re able to balance it better.
For new work, we’ve reduced the number of planned stories on the board to a minimum and have a clear priority order.
The team are now in the habit of making all new tasks visible on the board without interrupting the flow of the stand up – it’s not such an effort to add new tasks any more.
There’s always enough of each coloured sticky pad and some pens right by the board. If the holders are looking empty, one of us restocks.
Progress and status are clearly visible at a glance so we know if we have a problem and whether to adjust.
The team felt like things were under more control. Allowing them to focus on doing their best work and to try other improvement & collaboration activities.
When the team started their next round of sprint planning we had another 5S lesson – Seiri…
The great thing with this team is that all stakeholders are on-site and easily accessible. Having faced a painful hurdle on their previous sprint with a story that turned out to be significantly harder than expected, they discussed and adjusted priorities with their sponsor.
They pulled the part-completed story off the board, moved it right down the backlog and picked up something cheaper.
The team completely reset their board at the end of the sprint – even with work started or planned but unfinished – just to remove all the noise.
Interesting (but obvious) side-note – Perceived value is influenced by perceived cost. If something looks too expensive, previously less-valuable items become worth discussing and implementing.
IF the team were going to continue unfinished work, they would re-evaluate the remaining and completed tasks, understand why they didn’t finish, learn and re-plan appropriately rather than assuming what’s on the board was correct.
Longer-term, I’m expecting this approach to also encourage more flow/pull-scheduling of stories. I’m aiming for us to only pull new stories onto the board when there’s a to-do slot free.
Finally I stepped back for a while to let the team self-organize and see if they could sustain the changes (a trick from my friend Carl). About 80% of the changes have stuck with no support needed. Progress tracking and clearing the board down have needed some revisits. There were specific causes for these falling over but they’ve been recognised, addressed and are back on-track again.
In Part 2 I go into more depth on each of the areas of the board, what they do and most importantly why use them.
In the last few years the concept of technical debt has really taken root. Teams discuss it and use it to ensure important leftovers get cleared, not just business-critical priorities.
Here’s a fresh verbal anchor…
“Priority Fatigue” – The wear that sets in if you do nothing but focus on the priorities of your products or leaders all the time.
If you’re using Scrum or Kanban; chances are you’re working through some kind of prioritized backlog of work. Most Scrum practitioners are aware that despite iterations being called sprints the team are actually running a marathon. Every now and again your team needs to take a breather and at the end of a release they need proper recovery time.
Clearing technical debt is a common way of recovering. Another approach used by forward-thinking organizations is to have periodic innovation days or weeks where everyone “downs tools” and does something interesting instead. Good team-building days or activities are a third option.
These are all ways of addressing priority fatigue on a team.
Weekends and holidays are the personal slack that we use to pay off some of our individual priority fatigue however many of us don’t actually rest any more.
Our lives are so full we don’t have time to recover. In fact, many people now continue (at least partially) working even whilst on holiday – it’s frequently expected these days.
In the same way we relieve priority fatigue for teams, consider taking time to step back reward ourselves as individuals in innovative ways. If nothing else; take some regular time out to do something interesting even if it’s not important. **
**Caveat: don’t overdo it! Strike a balance with your priorities.
Back in about 2004 I was really proud of myself for coming up with the term “Egoless Development” in explaining my team’s approach to self-organization and collective code ownership. The concept was actually invented some years earlier than my use of it.
(egoless :: proud – an oxymoron perhaps?)
Somehow I doubt the author had Egoless Daily Stand-Ups in mind though…
Most of the variations I’ve seen on the 3 basic questions in a daily stand-up have a small but significant issue in common – they’re entirely ego-centric.
What have I done since yesterday?
What am I planning to do today?
Do I have any problems that would prevent me accomplishing my goal?
There’s a mountain of guidelines on daily stand-ups (some of the best being Martin Fowler’s) so I’m not going to retread these. All I offer here is a tweak in thinking.
These are about the team, not you…
Consider these – either as questions themselves or in your approach to responding to whichever questions you use for sharing with the team…
What have I finished or accomplished that others on the team need to be aware of?
What am I going to “open the lid” on that I should confirm with others before starting?
Where am I stuck, who can help me and how does that impact the team?
How is the work you’re performing going to aid the teams commitment or goals?