Saturday, 22 April 2017

Why do agile IT 'projects' fail?


"It's meant to be an agile project why are we still making changes?" "Why didn't you capture those requirements earlier?" "It meets MVP why can't you release?" "Why are we only discovering these issues now? It needs to hit this deadline so no more changes!"

Does any of that sound familiar? It's something I've heard lots of times.

Unfortunately by the time people are asking those questions it's probably already far too late. I'd probably go further... Most IT projects have already failed before a single line of code is ever written!

So why? The problem certainly isn't because it's an 'agile' project! I've seen many of the same problems with waterfall deliveries!  

The Waterfall Sandwich!

So... You take a development team and decide they'll be agile, Agile with a little 'a' of cause  - We couldn't possibly be totally agile because the risk of failure is too great! We'll use Scrum, Perhaps use a manager or PM to be Scrum Master and then surround this with the most expensive bread we can! This bread is the existing procedures and mindsets that have always existed.

We don't deliver value until we can deliver everything,  The plan is rear loaded with risk, Pressure around release is enormous! Because we don't release until the very end - It's all or nothing. Senior managers have not brought into agile thinking.... Agile is something thats only done in development! The pressure gets high, We try and remember agile principles but the support from PMO, SLT and senior stakeholders just isn't there... They've still in the waterfall mindset!


MVP

Minimum Viable Product - A term that I try and never use!!! It's been picked up and used by so many and understood by so few!!

Projects often have many risky areas and assumptions - The way we build software all too often still loads these risks towards the end of the project! We need to turn that thinking on it's head! Areas which are tricky or dangerous need to be tackled first!

Lets scrap the term MVP! Instead how are we going to test our riskiest assumptions? Lets develop the software to validate our thinking before building the pretty UX or main functionality.

Try and get the software in some format in front of a customer ASAP - Get some feedback - Test the need/demand/appetite for the solution! Design the software so it can run (live) in parallel with existing systems to reduce risk. Get something live fast... Test the target hardware early. Test scalability early on don't build a system that you know needs to run for 1000's of users and only test in the last few weeks as if it's a mere check box activity.

If you want your Product Owner to agree to releasing a cut down version make sure that you continue to deliver software after that point....  One retailer I was doing work for would constantly complain that their PO's didn't understand MVP as they would insist on everything being complete before agreeing the software to be released... But the same organisation would axe funding and break up scrum teams as soon as MVP was delivered! No wonder the PO's acted in the way they did!  The system in which the teams and PO found themselves led to this behaviour!


We use the wrong metrics and reporting to give us confidence 

There's probably a RAG status somewhere that gets reported back on... We all know how the RAG status works... It's green for 80% of the project, goes amber and then red just before the end when the development team suddenly discovers another six months of work to do! Everybody acts surprised and shocked even the IT veterans that have survived many campaigns in the past seem genuinely shocked that this could have happened - Despite as far as I know this is how the RAG status has always worked on IT Projects?

Why does the RAG status start life green? The start of a project is where we have all the risk! We have unknowns, unvalidated assumptions, assumptions we don't yet realise are assumptions! Why don't we start red and go amber and green as we move through a number of points that validates our thinking? Why don't we turn the RAG status on it's head and assume risk is upfront until we set out how to prove otherwise? Dedicate effort not to be seen starting new functionality but in prototyping and conducting meaningful spikes.

We use burn down charts (Something that the CSM course and software vendors have made the accepted standard) - I never use burn-down charts, they are more or less useless at best and possibly dangerous in the wrong hands!  If you're going to use something like this go for the CFD (Cumulative flow diagram)

However I seem to remember reading somewhere that 'Working software is the primary measure of progress' so why don't we use that metric? Probably because we're in a waterfall sandwich and telling those we can't measure progress until the very end wouldn't go down well...... And it really shouldn't go down well.... Unfortunately rather than changing the system so we see working software early we come up with metrics to help us feel better and to give everyone false comfort.

An awful lot of companies would do well to report back on the number of releases to production per quarter for their projects! A simple metric which takes almost no effort to collect! But would be very telling and might change behaviour in a positive way!


Estimates

Estimates are always wrong - So get over it! We're not working in manufacturing or even batch job production, We're working in complex, highly variable knowledge based work. Much of it is more akin to R&D - genuinely no 2 jobs are the same. Teams are not building brick-walls over and over again.

I know that this is unpalatable - But lets just accept that estimates are always wrong - stop wasting effort trying to come up with better estimates (which are equally wrong) and perhaps start to think of other ways of working to reassure those who fund projects.


The rest of the Waterfall sandwich! 

Sorry to all my Project Manager friends! It's not their fault! And they are often just part of a flawed broken system! But PM's are measured against certain criteria... Usually if a project is delivered on time or cost! Or delivery against a plan! We've been taught that veering away from a plan is a sign of failure! People are scared to admit that reality is different - We're told that the plan can't change again! The reality is that the plan WILL change and we should welcome that - Not live in a world where we fear admitting to deviating!

Unfortunately all of us are rarely measured on what really matters!  What if instead successes for the PMO was based on the client loving the new product? Or the original intention of the solution being met!!! Not does it meet the requirements that they thought they probably needed many years ago!! But has the solution enabled that saving of X million as promised? Or enabled a strategic portfolio goal to be met.

Most people's behaviour is based around how they are measured.... The Firewall team that has to approve and make those changes required to go live are not measured by the success of your project... There measured against a SLA.... If they do exactly what's been requested not what's needed well thats not there fault! They've done what's been asked of them! And so this depressing trend continues throughout the system!

What if the security team doing that penetration test decided to get involved early with the team... Spoke about what usually causes problems.... Looked at ways of working with the team to try and prevent... Rather than what happens so often - Which is that the security team are thrown a solution to look at a week before go-live... And again the security team are not measured by how many projects they enable to succeed - If so they might behave in a different manner... Their measure of success is that a security breach  never occurs! I'm not saying that's a bad thing... But the safest way to ensure that you don't have any type of breach is to always say 'No'!


Group Think

This is something I want to dedicate an entire blog post too. I've been in many meetings/planning sessions with senior managers, Executives sometimes development teams - The plan is talked through.. There's a unspoken pressure on people to conform and accept the plan... Disagreement is frowned upon.. Perhaps it isn't but it feels like it is or will be...  Those that perhaps do challenge are told that we must hit the deadline, Failure is not an option, There is no plan B! Teams go along with plans which are flawed from the start.... A month in and the project is already falling behind.. Do we put our hands up and say that the plan has been invalidated and we need to re-plan? Or do we convince ourselves that the time will be made up later? Its nonsense... We've designed a plan which probably loads most of the risk towards the end and we still think that lost time early on will be made up in the most riskiest phases of the project - But still everyone nods there heads and goes along with it.

We just need to be seen starting this

I've lost count of the number of times I've heard someone say the line 'We just need to be seen starting this, We need to give so and so confidence that it's in hand' Everyone knows the Kanban line 'Stop starting, Start finishing' But it couldn't be more true.

Projects loose focus, They start more and more things, WIP (work in progress) balloons, Queues start to form, Context switching begins... We have a hundred different journeys to test and go through but none of them work... We don't stop and finish what we have! Instead we start something else - We can finish that code later... We'll integrate at the end of project.... Just before that enormous big bang release we've planned!



Complex and Expensive release procedures

All too often the process of pushing software out is hugely complex - I don't want to go into DevOps or automated testing in this blog post.. It's already long enough! But highly complex release procedures add to the risk! Its a barrier to releasing frequently which results in a lack of learning early. It encourages a culture of trying to push as much into each release as possible which then ironically tends to further delay releases, increases risk............

Process which prevents software going into production which isn't fully tested and UAT'd is part of the problem.... Design systems in a way where it can be safely pushed into production even untested! Release software switched off, Release API's in parallel to existing API's  - Design software which can test API's in production before they are fully switched on. Put effort into designing ways to release software that might not be fully working early but safely!


Distributed teams

If team members  are on different floors communication begins to fail! I've recently read research that shows that once team members are more than 20meters apart communication drops significantly... And its true! Throw outsourced teams into the mix - particularly when they are working on non T&M contracts and things just get worse!

I'm not saying that distributed teams cannot work... But you have to work an awful lot harder to ensure that they do work! And that also costs money!


Training


So often training seems to be missing... At all levels! Many developers have never worked in a 'genuine agile' environment - Usually they may have done bits of Scrum only, Everyone on the team will have different understandings of what Scrum and Agile mean..... Which is fine but they often don't have agreements as to how they will work together.

Many people believe that being agile is something that applies to the development team only and so they don't need training... Senior leadership are rarely well versed in being agile or what it means to be agile. Don't underestimate the need  for training and to have coaches on site... Coaches to the business not just IT

Projects!

The constant ramping up and down of project teams is wasteful - It disrupts flow, knowledge, team cohesion the list goes on! Projects are by default temporary structures created to implement highly complex change. But we know that change is continual albeit capacity/demand may be variable. Project funding leads to poor decision making, deadlines don't make sense and actions are taken which increase risk.










Saturday, 4 February 2017

Clean language for Agile Coaches!


I've been seeing a lot of talk and activity around the use of Clean Language with agile coaching... But what is it? And what's it all about? To find out more I did a 2 day course back in November last year ran by Judy Rees and Olaf Lewitz to try and delve deeper...

Clean Language is a technique developed by David Grove in the 1980's which was a result of clinical work helping to resolve clients traumatic memories - Encouraging clients to develop and build metaphors which are then explored using clean language questions.

I really struggled with the course - I couldn't do the metaphor concept and as a participant I couldn't construct metaphors for people to explore,  I must have been a right pain for those pairing with me!  I left feeling very uncertain about using it....

However I've since experimented with it several times - In coaching sessions and retrospectives and have been really surprised with the conversations and insights generated.....

So myself and fellow coach Arif Bobat decided to put together a quick course to get across some of the principles in a training session for other agile coaches working for a client of ours.

And here it is...  Clean language in 90 minutes. This certainly isn't a deep dive into Clean Language, But it does cover many of the core basic's you'll need and point you in the direction of further reading!



Exercise 1 - "When you're learning at your best, That's like what?"


Pose the question :- "When you're learning at your best, That's like what?"... And perhaps give an example.... "When I'm learning at my best, It's like my mind is a sponge" (Note the metaphor of the sponge) - The idea is to create metaphors which we will later explore.




The syntax is important so pay special attention to it.

Give the room a minute or two to think and then in pairs :-

Person 1 asks :- "When you're learning at your'e best, That's like what?"

Person 2 replies :- "When I'm learning at my best thats like.........."

And then mix the pairs up and repeat until everyone in the room has spoken to everyone.









Exercise 2 - The Lazy Jedi Questions


Moving swiftly on.... We introduce the 'Lazy Jedi Questions' These are the only two clean language questions you'll ever need!!! (Well perhaps that's not totally true) But for now they fulfil the Pareto principle! So learn and practice them!




Going back to the metaphor created in exercise 1 and still working in pairs.

Person 1 asks :- "When you're learning at you're best, That's like what?"

Person 2 :- Replies with their metaphor

Person 1 :- Explores the metaphor using clean language questions....

"What kind of X (Is that X)?"

"Is there anything else about X?"




Again - Switch pairs and afterwards discuss what happened as a group....

As the facilitator experiment using clean language in the discussions.



Exercise 3



This is the listening exercise... Great fun to watch as the facilitator, especially round 2!



Round 1.....

Arrange the room so that people are sat in pairs.

Explain that this section is about developing listening skills.

Give everyone a minute to think about a subject they would like to talk about, any subject but they will be talking about it for 2 minutes.






Then in their pairs :-

Person 1 (the talker) :- Talks for 2 minutes on their subject. 
Person 2 (the listener) :- Encourages the talker to talk for the full 2 minutes using non-verbal communication only.

And then the pairs switch, Listener talks, talker listens.

Once everyone has had a go listening and talking - Get together as a group to discuss.


Round 2......

We're now going to repeat the same activity - Except this time the listener will act distracted and uninterested... Again the talker will be speaking for 2 minutes.

Person 1 (the talker) :- Talks for 2 minutes on their  chosen subject

Person 2 (The listener) :- Still using non-verbal communication acts distracted, looks away - does everything they can to show no interest in what the listener is saying.

And then swap!

At the end of this round discuss with the group, How did people feel, Is there anything else about that?


Round 3 (Introducing the Repeat)

We're going to introduce a new concept now..... The Repeat

There are many psychological studies on this subject and it's too massive a concept to go into here.... But in summary people like people who are like them, When Servers in a restaurant repeat a customer order the customer subconsciously feel that the server is more like them than not (They experience sameness with the server) People who are good in rapport mirror each other's gestures and speech.

In this round the listener again uses non-verbal communication techniques to keep the talker talking... But they also pick out words or phases to repeat back to the listener...

When myself and Arif introduced this technique  in our training session we role played the following scenario as an example.....

Facilitator 1 :- "What would you like?"
Facilitator 2 :- "A pint of Bass"
Facilitator 1 :- {Nods}
Facilitator 2 :- "A pint of Thatchers" 
Facilitator 1 :- {Nods} 
Facilitator 2 :- "A packet of pork scratchings" 
Facilitator 1 :- {Nods} 
Facilitator 2 :- "And a packet of those posh crisps over there!"
Facilitator 1 :- "Ok"

We then repeated the exercise using the repeat.....

Facilitator 1 :- "What would you like?"
Facilitator 2 :- "A pint of Bass"
Facilitator 1 :- "Pint of Bass"
Facilitator 2 :- "A pint of Thatchers" 
Facilitator 1 :- "A pint of Thatchers"  
Facilitator 2 :- "A packet of pork scratchings" 
Facilitator 1 :- "pork scratchings" 
Facilitator 2 :- "And a packet of those posh crisps over there!"
Facilitator 1 :- "Posh crisps"

Again as a group discuss both of these scenarios - How would you feel being the customer in both cases?

In one study - a waitress was able to increase her tips by 70% by employing this technique - It's also a technique used in the book 'The Game: Undercover in the secret society of pickup artists"

It's now time to practice.... 

Person 1 (The talker) :- Again talks for 2 minutes on any subject they like 
Person 2 (The Listener) - As in round 1 actively encourages the talker to talk... But this time they use the repeat - They may also like to experiment with the lazy Jedi questions
"What kind of X is that X?" 
"Is there anything else about X?"


Again at the end of this exercise discuss - How did it feel? What happened when the talker had their words repeated?




Exercise 4 - The Power Switch


This where it gets exiting... And we introduce the powerful 'Power Switch'

Person 1 :- Talks about a problem
Person 2 :- Listens (Intently) - And then repeats the problem and asks "And when {problem} What would you like to have happen?"
Person 1 :- Replies



Each pair takes it in turns an if time allows mix up the pairs.

Again as a group discuss... What happened when the power switch was used?















Friday, 9 December 2016

Portfolio Management with Starbucks


I've been trying to design a game which will teach some agile & lean principles around running a portfolio of work.. And to be honest I've been struggling!! So many learning points to get across whilst making it fun.

Anyway - I've been doing some work today with some teams that are using SAFe..  Upon arriving back at Euston I find my train is delayed.... Yet again! So I decide to spend 42 minutes or more in Starbucks.....



Whilst watching the queue in Starbucks I observed that just about every behaviour to explain portfolio management can be learn't from watching the queue in Starbucks!

For those familiar with Little's law - The time between joining the queue and being served (delivery) is relational to the size of the queue (Lead time). Okay.. Nothing surprising there!

However the speed the queue moves at is variable..... But why.. Well if everybody in the queue orders a single cup of tea (And that's all you should order, A nice tea) the queue moves at a predictable speed... However if most people are ordering tea and then somebody comes along and orders 6 Chai latte's for everybody in their team back at work all of a sudden the queue stops moving! Variability has been added to what was a predictable system.

And then... Somebody joins the back of the queue and spots a friend near the front.. So what do they do? They add their order to their friends order which caused even more uncertainty and irregularity to the flow!! Okay so I made that last bit up, That never happened! But how many times with projects do you see that? PM's buddy up with a mate and piggy back part of their projects onto somebody else's?

Then when Starbucks see that the queue is getting long... What do they do? They send somebody out to take everyones order! This really annoys me has It hasn't nothing to do with speeding up the queue.. Taking the order isn't where the constraint in flow occurs! The constraint it usually the coffee machine(s) which are optimised for 2 drinks at a time - Taking people's order is merely to keep them in the queue and to stop them wondering off somewhere else... Sounds familiar?

I did some consulting work on a eCommerce product a while back and one of the major objectives was to reduce lead time.... So.... How did I achieve this? Well it's really easy.. I just shortened the queue!  Short queue equals short lead times!

It was a tough policy (not one that I expect Starbucks to implement)... The queue couldn't be more than 3 months of work! (Well not totally true... but almost) once full nothing else could be added! The result meant that if you got your idea into the queue you knew it would be implemented within a maximum of six months... Usually less than three.

Every three months projects would need to be reviewed (including any in the system)... The benefit (business value) re-examined and fought out with other projects... The projects that were SMALL with the most business value won and were allowed to join the queue! If your project wasn't small and you really needed it done.. Well you had to find a away to make it small enough and to still deliver value!

I still haven't designed my portfolio game.. Perhaps instead I should invite them out for coffee instead.

PS.

For more info on Little's law.... https://en.wikipedia.org/wiki/Little's_law

PPS.

For those wondering...... Starbucks has not sponsored this post!



Saturday, 19 March 2016

Story Mapping


I've used the technique of Story Mapping countless times at project inception to assist in understanding the problem domain area, ensuing a shared understanding of the problem and a collaborative approach to building a product backlog. Unfortunately I can't really claim any credit for this methodology!!




Story mapping starts with an overarching vision of what's required...  And is then broken down to a more granular level.

I did this exercise with a large well known e-commerce brand...... Working on high level user journeys within the system- Done with blue index cards - The colour isn't important.. But it's nice to visually see the different types of stories/epics or NFR's (Non functional requirements)


  • Browse the catalogue
  • Search
  • Add to basket
  • Payment 
Each section was then broken down into smaller stories.... So Payment was broken into different ways of paying

  • Card 
  • PayPal
  • Yandex
  • Gift Cards
  • Account customers


We then tried to find the simplest user journey which took us through the entire system.... drew a line and move everything story which wasn't part of this journey below...

We then began an exercise of iteration release planning.... The teams would be working in 2 weekly sprints with the view of each programme increment being 5 sprints....

We then began to work out what users stories we'd aim to complete in each PI (Programme Increment)


Conclusion

Story mapping is great for project inception... It's allows a backlog of items to be quickly built in a very visual structured way. It creates a shared understanding of what's required and what we're building.

It's also a brilliant way for slicing work into increments... Which also allows us to monitor progress and adjust our release planning!!!













Saturday, 7 November 2015

Working Agreements


A team’s working agreement is a set of rules/behaviours set by the team itself to govern how the team will function.

It’s important for the team itself to come up with the list of rules (As ever the Scrum Master 
should be there to facilitate the meeting) the team is also responsible for enforcing the rules!

Some of the Items to include are…..

  • Definition of Done
  • Definition of Ready
  • Conduct in meetings


I usually find that the retrospective is a good time to both define this artefact and to refine as required.

Some of the rules previous teams have come up include…..

  • Already be on time for meetings (And the stand-up)
  • Always listen to others and don’t speak over people
  • No mobile phones in meetings
  • Don’t commit to unknown stories
  • Don’t estimate on work with no acceptance criteria
  • Stories over 8SP need breaking down smaller
  • Physical and electronic board kept up-to date


Thursday, 6 August 2015

Metrics in Agile


I've been meaning to write a blog post all about metrics for a very long... It's a really important subject and one that doesn't get spoken about anywhere near enough - I also plan to come back and add to this as time allows.

Metrics in Kanban as opposed to Scrum is perhaps more common place, Kanban is much more a case of bench marking where we are, Conducting 'experiments' and measuring the result before rolling back or continuing.

But, Good metrics not only allow you to understand the effects of experiments made but also allow you to start planning with at least something approaching a scientific methodology! Although admittedly it does take more effort than the old finger in the air, double it + a safety margin trick that!

Below are some of the main metrics I use regularly.

Flow efficiency

I love this little metric - It gives a quick indication as to how efficient your process is.

The exact way you record it might differ based on what you're trying to measure... but roughly, Record the date a story is requested, record the date it's released and record the number of days it was actually worked on.

So if a story takes 20days from being moved from the backlog to the todo column and is worked on (developed/tested/etc) for 5 days you have a flow efficiency of 5/20= 25% Which although looking low is probably a really good figure!


Cumulative flow diagrams




I love a good CFD... It's a really good visual way to track a project. Most software tools will allow you to generate a Cumulative Flow Diagram - Otherwise you can export the data to Excel and generate one.

Generally speaking the closer together the lines the lower the WIP (Work In Progress) and shorter the lead times should be and the more work should get done (green)

You can see from the graph a very flat section early on where no work was getting done - That was before I joined as Scrum Master ;-) And another slight decrease in work 'done' and a longer lead time about 3/4 along... That could be a cause for concern.. It was actually the Christmas/New Year period but it shows graphically how well a team is working and how much work is left - These are great to take into retrospectives.


Lead Times

Lead times.... Are simple, How long from requesting a story (Moving from the backlog to todo) until release (or 'Done')

However you probably want to start recording lead times by story/ticket type.....

If your using story points starting plotting lead-times against story points using a histogram.

You start to get some really useful information back,

For example - You might be able to say that 85% of stories estimated at 13SP are delivered in under 5 days but up to 5% take longer than 10days.. However 50% are delivered in 3 days or less.

Having powerful metrics like this allows you to really plan... You can pick the right time to start doing work and know with a level of confidence when it will be complete.

You can prioritise stories more precisely - Knowing you can leave that really important legal change story until 10days before it's required as it's estimated at 13SP story which than means you can work on the 20SP story first as it'll save X-thousands every day!


Cycle Times

Cycle times are very common in Kanban and Scrumban...

It's a measure of the number of tickets in progress and the number of tickets completed daily - You can sample at different rates but I tend to run Scrumban in weekly cycles but different teams will work differently.

So... To keep the numbers simple, If you have 10 tickets in progress and complete 2 a day (average) - You cycle time is 5. 10/2

You should find if WIP increases so will the cycle time and the opposite too!

Start plotting cycle times and you'll begin to see trends... And trends are how you know it you're improving... or not! It's also useful to start plotting different types of tickets together - So below we can see that the cycle tine in May/June increased from the norm... But so were the cycle-times for bugs... You can't draw a conclusion from this but you can ask questions and understand.







Happiness/Satisfaction

This probably gets overlooked more than any other measurement. But measuring the happiness of your team and customers is probably one of the most important... Reality is important but perception probably more so!

This can be especially important if running an agile transformation... Bench mark how happy the team is! Understand your customers issues/concerns and overall level of happiness with the service.



You could create a mood wall, questionnaires, etc. The The mood wall in particular are really good for discussing in retrospectives.


Velocity!

Well I couldn't write a blog covering metrics without mentioning it...  But I don't really want to discuss it too much on this blog, Velocity is fine for an internal team metric and helping to predict burn-down against a backlog or for allowing meaningful negotiation about story sequencing, etc.. But don't get carried away with it.. Try not to chase it and don't let people abuse it!

And if you do want to know more..... Velocity


Burn down

The burn-down chart - These are very common in Scrum, both for tracking progress in a sprint and for measuring against the backlog.

I must admit... I'm not really a great fan of the Sprint Burn-down - It seems to have become another chart that management overuse (Like velocity).

You should be able to track progress of stories completed via the Kanban/Task board.

If you are doing a sprint burn-down - Perhaps rather than looking at hours against tasks and burning down perhaps looks at the number of stories in the sprint and burn down against that measurement - It's actually recording what's important (Completed stories)

I do however like a burn-down against a backlog (Although if you're using the CFD - this is less important) If you do have a well estimated well 'refined' backlog and you have a stable velocity figure these can be useful to either predict delivery or to alert early on that you're going to miss a release point.


In Conclusion 

Metrics are important...  They allow you to safely change the workings of a team and understand the effect. Management typically prefer's this way of working, it's safer and you have evidence to back up decision making.

At the planning level metrics are invaluable - And allow you to plan with some confidence.... Although planning when you have actual metrics suddenly becomes a much more complex and tiring process than just guessing it!

But you have to them use metrics responsibly and remember Goodhart's law - "When a measure becomes a target, it ceases to be a good measure."

Try and keep away from absolute numbers and monitor trends instead - The CFD's are brilliant for this - Look at the general trend not specific numbers. Don't chase a number but try and understand why those numbers are changing.


   

Friday, 31 July 2015

Kanban, It's not just boards and post-it notes!

Read most blogs discussing Kanban and they’ll discuss setting up a board, Identifying lanes (Backlog, Ready to start, In progress, Test, Done, etc.)  and moving post-it notes across – Perhaps the blog will go as far to discuss WIP (Work In Progress) limits – And pull rather than push principles and that’s it Kanban!! And I’m just as guilty as my blog from last year shows! Kanban

I can't see the WIP limits! 
Ironically if you look at the roots of the Kanban….. Which is in Japanese Supermarkets (Not Toyota, Toyota at one time referred to it as the Supermarket method) there is no Kanban board - Just a token.

Kanban thinking is a methodology for understanding systems. When I introduce Kanban I like to run a number of workshops.

The first is to understand the purpose of the system and to create a shared understanding and context…

It’s important to have the right people in this workshop… And the right people will vary from company to company! But ideally you want representatives from all parts that the system encompasses – If you’re working in the digital arena this might include UX designers, marketers, developers, testers, and importantly people from the business for drive innovation, ideas and projects through the system.

But.... Before getting into anything too serious it’s worth doing something a little light hearted – I like to use http://www.drawtoast.com/  This exercise involves everyone drawing a systems model as to how they make toast – Something simple which we all understand… And then appreciating the many different ways of achieving something so simple and well understood?..... Not to mention the artistic skills or lack of in your team!

Once the fun stuff is done you want to start discussing the purpose of the system… Why does it exist? What’s the objective of the team.. What problems do people have? What opportunities are there? Possibly get ready for some serious facilitation at this point.

The output of these sessions will vary – But hopefully you’ll have created a shared understanding and purpose – you’ll probably discover things about the system you never knew! And hopefully people will gain an understanding as to each other frustrations.

It's important to record these finding and to take them away with you - I like a lot of the work Karl Scotland's done with Kanban thinking and I like to leave with the following headings..... Kanban Canvas

  • What are we going to share? (Board, tokens, etc)
  • Study - What are monitoring? 
  • Value - What's the value we're trying to achieve?
  • Potential - What could we achieve?
  • Sense - How are we going to monitor the system, understand it and plan?
  • Stabilise - WIP, Acceptance criteria, Definition of Done

How you document or record these are up to you.... Brain storming (mind showers as I think is the new PC term) whatever! Just ensure that these points are understood, recorded, public and importantly re-visited!

The 2nd workshop I run is the more familiar what is Kanban….

This talks about the infamous Kanban board and designs for Kanban boards… Everybody has seen the conventional layout but there’s no reason to stick to it! Well there are reasons to stick with it such as shared understanding and ensuring that people can easily read different Kanban boards... However I was on a training course recently and saw one team design a brilliant spiral Kanban board with tickets entering and moving through stages until reaching done... The width of the spiral dictated WIP and there was a channel to expedite tickets via!

Again it’s essential to have the right people in this meeting…  I’ve seen too many Kanban boards only model the work of one team. The Kanban board(s) should help to visualise the system not one small part - Everybody in that system needs to be involved and have ownership.

Next look at the design of the Kanban ticket/token….. This might sound boring but it’s important! What information will the tickets contain will you have different shapes and colours for different types of tickets? What metrics will you record? Start date, end dates, dates worked on  (Handy for calculating flow efficiency) What about recording movements on the board… Tickets tend to move left as well as right (assuming your direction of travel is left to right)

In this workshop I then go to discuss WIP– I often play a game created by Mike Burrows -  Featureban to explain and demonstrate some of these principles and it's a really good discussion game for the group. What are the advantages of WIP? What effect does it have on the size of the backlog? What does that mean for lead times and the ability to change direction quickly?

I then go on to discuss the concepts of agreeing WIP limits even if you don’t stick to them straight away… But do make them public and acknowledge this.

Next I discuss one of the hidden treasures of doing Kanban – Metrics and for this I usually get the group to play the  'Penny coin game'

This brilliantly shows how you go from an unstructured unpredictable system to one that’s almost clock-work – And how implementing Pull principles with WIP limits will balance a system and help to identify its natural capacity. Metrics will help you to measure and bench mark the system.

The next concept to discuss and perhaps the most important is the retrospective…..

When introducing Kanban one of its selling points is the “Start with what we do now” – This makes adoption much safer! I’m a massive fan of Scrum… But I’ve also seen plenty examples of failed Scrum.

With metrics to understand how the teams currently works you can start to make 'safe' experiments (Discuss these in the retrospectives) and then observe the effect on the metrics… If it works carrying on – If you try something that’s detrimental  you’ll know and you can make the decision to roll back. Importantly it means that decisions are made on metrics not gut feel or as Google call it Hi.P.P.O's Highest Paid Persons Opinions 

Kanban should be about evolutionary change not revolution - You make a hypothesis conduct an experiment to test and measure!

Finally - Before implementing these changes you need a go/no go decision! At the end of the workshop after speaking with management you need to decide if you're going to go ahead and implement change or not - Not all teams are ready and not all management is ready yet - This takes real courage but if the backing isn't there it's perhaps best to wait until it is.

If you do go ahead - Select somebody to enforce the process, we might not have a Scrum Master in Kanban but do we need a flow master/Lean Manager - Somebody who will ensure that policies are adhered too, the Kanban board is being updated, metrics are being recorded and used - Somebody to facilitate meetings.

My one biggest tip to anyone looking at introducing Kanban... Is perhaps not to call it Kanban! People come with a preconceived idea of what’s Kanban is all about – So if you’re running a workshop to introduce Kanban perhaps consider calling it something else!

If you want to look at, borrow or use my any my slides or materials....  Feel free to do so, I'll add more materials as time allows!

https://docs.google.com/presentation/d/1syZyx7pRsR3yAaxLWZAD2nJi8IQxep2N6wqqIwtNAZI/edit#slide=id.g375a7f99e_16

Sunday, 19 July 2015

Breaking down technical (non)user stories!

There’s plenty of articles discussing patterns for breaking down user stories… I’ve even written the odd article myself.

But what about breaking down large complex non-user stories? I often warn of the danger of creating too many non-user stories or too many technical stories as they can tend to lead to horizontal development thinking as opposed to vertical slice delivery and make enforcing a definition of done less transparent…. However some systems simply don’t have user stories – Or at least not many!

This is real user-story from one such system….

“As a customer of …… bank  I would like to purchase half a billion Euro’s in sterling for the best rate available”

This was a user story I was discussing with a product owner for a large bank who was struggling with this issue – The system they were developing dealt with High Frequency trading and was mainly algorithmic based.

The system had to purchase a given quantity of a currency at the best possible exchange rate and hopefully without pushing the value of said currency up (too much) during the purchasing.

The product owner wanted to use user stories, Planning poker to estimate and deliver fully working, fully tested code each sprint and demo it!

Traditionally in a user story we would write something like…

As a <type/persona> user…..
I want……
So that…….

We would further defining the criteria with BDD (Behaviour Driven development) a possible BDD scenario for our bank customer could be….

Given… The exchange rate is 0.69 = 1 Euro
When…. I purchase 100,000,000 euros
Then…. I’m able to purchase for no more than £69,000,000

We came up with the idea of treating technical parts of the system as users - We even discussed the idea of giving each part it's own persona and name (But we were perhaps getting a little carried away at that point!)

  • As an API when I receive a request to check the value of transactions in a currency since trading began today I will return a message with the following details.......
  • As a listener I want to be alerted when the exchange rate varies outside of a defined tolerance   

Those 'user' stories are still a little high level and you would probably want to break them down further.

  • As a listener (ListerName) I want to receive a 12000 message containing (..........) when the value of sterling against the value of the euro drops below the value held in dbo.clientprojection.MaxExchangeRateValue
  • As a listener (ListerName) I want to receive a 12005 message containing (..........) when the value of sterling against the value of the euro drops rises above the value held in dbo.clientprojection.MinExchangeRateValue

These stories would then be surrounded with Behaviour tests and written up using the Gherkin language.

In this way although the coding is much more 'invisible' as compared to a system with user interactions the PO would still be able to monitor progress.

The delivery of each sprint would be 'potentially shippable' and indeed could be put live even though it might not  add business value it would allow the release procedures to be tested and the system monitored in a live environment before being used in anger!

It also allowed for the PO to enforce the definition of done, Track velocity and make a very invisible system visible.




Saturday, 11 July 2015

We really need to STOP measuring knowledge based work in man hours!

Last night I was having a quick browse through one of the most famous essays ever written on Software engineering, "The Mythical Man Month”... I don't think I've read the book in over ten years during which time its been sat quietly collecting dust on my bookshelf! To my surprise when flicking through I noticed that the original version was published in 1975 making this year the 40th anniversary - However despite being marginally older than myself it shows perhaps how little has changed in the last 40 years! 

A while back I was doing some coaching with a team roughly made up of 4 scrum teams of 10 people - The product being developed was late and over budget...  

The knee jerk reaction was to throw yet more developers at the project, The effect? Well anybody who’s read the book can probably already guess - But for those who haven't suffice to say it didn't help matters! 

One of the issues in terms of governance and reliability of estimates was the obsession with the man hour. All work was estimated in hours.... The total project time was calculated in man hours and the number of hours worked per sprint were recorded. Ensuring the project was on track was as simple as subtracting the number of hours worked per sprint from the total project size - To be fair that is a slight simplification of the reality... But I do mean slight! Senior management were happy that this method of tracking hourly burn down ensured that things were on track and PM's ensured that the scrum teams were loaded up with around 3000 man hours per sprint.

Unsurprisingly the project began to run late - Alarm bells weren't triggered early because the burn-down charts all looked good! Work was being allocated by squeezing jobs based on hours into the sprint... Which had the effect of ballooning work in progress and decreasing work fully completed and tested - ' Tasks were allowed to stretch over multiple sprints and all the while more was was being pushed in..... All to meet the 3000 man hour target per sprint.

I'd like to think this was a unusual setup (Well I wouldn't... Otherwise I'd find it harder to find work!) - But time and time again I meet with and talk to managers who are obsessed with measuring and estimating in man hours! I have yet to be shown what the standard output per man hour is? Unlike working in a factory producing the infamous widget where output is tangible and quantifiable (You can count the number of widgets manufactured per hour) software isn't so simple!  Perhaps these managers are measuring lines of code per hour! Which would be funny except that I've actually seen it done!

I don’t have a problem with the concept of measuring the productivity of widget manufacturing using man hours... Particularly if you happen to be living in the 19th Century and you go to work wearing a top hat everyday....  But that's exactly where such management techniques belong.

Apart from being a totally useless method of measuring productivity, Estimating deliverables or applying governance - It's actually harmful to the team's performance... I witnessed an example recently with paired development - Why am I paying two developers to work on one problem when they could be doing twice as much work individually? Most of us who are experienced in software development are well aware of the advantages of paired development but sadly this view is still very common.

Going back to the team I was coaching.... I quickly discovered that the retrospective had long been abolished - Despite the retrospective being perhaps the most important of the ceremonies... However it had decided that the retrospective was too expensive 40 people (4 scrum teams of 10) in a meeting for an hour means one lost week of productivity... And that didn't look good on that hourly burn-down chart!

The below Cumulative Flow Diagram shows a different story to that of the burn-down charts - It was just unfortunate that nobody looked at it!

Not the actual CFD - But the trends closely resemble the actual graph!

Massive Lead times between work starting and being completed… Too much Work In Progress - And not enough work marked as 'Done' -  Despite the above graph clearly showing a problem within the first couple of sprints alarm bells weren't raised until 6 months into the project.

As a Scrum Master I generate metrics all the time :-
  • Flow efficiency
  • Lead times
  • Velocity (You need to be careful with this one)
  • Histograms (Ticket/Story completion by type and/or size)
  • Cumulative Flow Diagrams
  • And the ubiquitous burn-down 

So why do managers insist on using a methodology which we all know simply doesn't work?

Perhaps it's because much of our thinking is still based on construction metaphors... But software is not construction.. We're not building brick walls... You can't measure quality or progress with a tape measure! Or by counting lines of code or recording time sat coding at a desk.... Some of my best ideas when working as a developer occurred over a cup of tea, Walking around the park or waking up at 3 in the morning with the answer! - How does that fit in with man hour management and costing?

I suspect the accountants hold some of the blame.. Projects and departments and teams are still costed at person level and Project managers are often expected to account and justify the cost of every person.

However - Sadly I suspect there might be a bigger reason why people are still addicted to the man hour..... It's just too easy! Ask the development team to estimate... They pluck a number out the air, double it and add 20% - The PM then only has to divide the project size in hours by the time available to calculate how many people are needed or the reverse to calculate delivery with a know team size... It doesn't get much simpler or wrong!

True project planning - Where you understand the average lead time of tasks and stories... Where you know that a story estimated at 8 points is completed within 5 days 80% of the time, Where you know what work is 'Done' and shippable and how much work is left - When you know the optimum time to start various bits of work because you have reliable metrics and you have a team that actually deliverers at a known sustainable, repeatable pace...  Well that takes a lot more effort and requires real thinking not sitting down with a calculator!

As a follow on from this blog I intend to write a series discussing useful metrics which help your team plan more accurately.



Monday, 15 June 2015

No Estimates

OK... I'm going to be honest... The title No estimates is a little misleading... But I wanted to jump on the #NoEstimates band wagon to increase my SEO rankings! But do please read on... You still might find it useful.

I was talking to a ex-colleague tonight about the use of Fibonacci number sequences when estimating tasks..... The Fibonacci (or modified Fibonacci) sequence is often used for story pointing and if your breaking stories down into tasks and then estimating the tasks in hours.. It's good practice to still use the same sequence.... So if you think a task will be 6 hours you round up to 8! (The modified Fibonacci sequence is 1,2,3,5,8,13,20,40,100)

I find estimating hours on tasks extremely useful with new teams... It's a very good way of encouraging a culture of breaking tasks down smaller.... I was working with one team where tasks were being estimated in sometimes hundreds of hours! In some cases tasks were spreading over multiple sprints... That's an extreme example but it's one where estimation of tasks becomes useful because it clearly shows that tasks are too large and encourages better task break down...  Imposing simple polices such as a maximum size of a task being 8 hours should lead to better story breakdown, better task breakdown, increased visibility and increased work flow.

However... When your team gets to the point where tasks are usually no bigger than half a day or perhaps a day at most... Is there still value in estimating? Or is it an additional unnecessary overhead?

I would suggest that if your team has the maturity of breaking stories into tasks which are a few hours to a day at max.... Then perhaps you can move away from estimating.

You can still do a sprint burn-down chart (For the record I'm not actually a great fan of the sprint burn-down.... But thats for a separate blog) But instead of burning down hours burn down tasks.... If you've got a 100 tasks over a 2 week sprint you should be averaging 10 a day - You should find that it has a very similar accuracy to burning down hours.... Without the overhead of estimation!

Thanks for reading,

Christian Miles

PS. Also check out my article.. In defence of story points and estimates! http://christianleemiles.blogspot.co.uk/2015/02/are-story-points-still-relevant.html











Thursday, 21 May 2015

In defence of blindly following the rules!

 
Those who know me well will know of my total ‘hatred’ of just blindly following rules without questioning the why, In fact I have a blog on my blog backlog titled ‘Great Agile teams break the rules!’
 
When coaching teams I don’t like talking about rules and must do’s but instead concentrate more on general concepts, ideas and the all-important reasons behind doing them! It’s also important for me to remember that whilst I might have many years’ experience with Agile I won’t have the experience that the team has with their own product(s) or such precise knowledge of company culture… They will be very much the experts in what will and perhaps more importantly will not work in their particular environment.
 
I recently worked with a company new to scrum who have by their own admission failed with the process, When looking at their implementation of Scrum I found that very few of the ceremonies or practices of Scrum were being followed…
 
  • I asked about Sprint planning sessions – But was told that it was too much of an overhead in time getting developers to breakdown and task work.
  • Story pointing – No… We estimate the entire project in hours
  • Velocity? – No
  • Backlog refinement – No
  • The retrospective – We don’t have time… It's too expensive!

When pushed further it had been decided that these activities were deemed unsuitable for the organisation and a waste of time…..
 
Now.. I have worked with some very good Scrum teams that don’t do planning sessions and don’t use story points (Google #noEstimates and take a look at Are Story Points Still Relevant) – However most of these teams started of following the rules rather rigidly – They were doing agile rather than being agile… But overtime they inspected their process’s, dropped what didn’t add value or what no longer added value…  But interestingly the company culture had been altered by being ‘forced’ to follow the ‘rules’ of scrum until they reached a point that they were able to be agile!
 
I was recently accused of being more interested in doing Agile then being Agile by a hiring manager looking for an Agile Coach!  Those who know me well will know I take a very pragmatic view on agile practices and that the ultimate aim is to help the business deliver value – But sometimes… You just have to blindly follow the rules so that you can get to the point you understand which rules to break!

Sunday, 22 March 2015

What is Agile?



What is Agile? What's meant by being Agile? When you think about it... It's amazing this question isn't asked more often! It's almost certainly not asked enough especially by companies who suddenly decide to go Agile in an attempt to fix all of their problems!

Perhaps more telling is that I've been writing posts on this blog for many years and it's only now that I'm addressing this question.




I've worked with several companies who have made the transition to Agile practices but what does it look like? How would you define the practices of being Agile? How do you know when you've got there? Can you ever get there?

Taking a look at the Agile manifesto is probably a good start... http://agilemanifesto.org/ They list the following high-level values:-


  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
But it doesn't really explain what Agile looks and feels like! Nor is it anything like a roadmap for implementation... It's not meant to be.

I was at an Agile meetup recently where this question was asked.... And even in a room full of Agile enthusiasts, Scrum Masters and delivery managers we couldn't define what the term really meant.

I suspect if I asked the question what is a Sports-car or what makes a good sports-car?  We'd struggle to come up with a definitive description that would fit every sportscar ever made! (With the exception of the mighty MX5 - which is probably the best sports-car ever!) 

Whilst writing this article I tried to Google 'What is Agile' the first page I got back talked about iterative time boxed product enhancements - That sounds like a high-level description of doing Scrum to me.... Which means if you're doing more of a continual flow model such as a Kanban approach you wouldn't be Agile?

Is it a form of project management? Like PRINCE2? I sometimes say I do Agile Project Management - I also talk at high-level about Agile techniques being an alternative to PRINCE2 - However those that have read much of my work will also know I often talk about using PRINCE2 as a wrapper around Agile practices to fill the gaps missing from frameworks such as Scrum and Kanban!

When I work with a new company who wants to move to Agile practices I often ask them the question... What is your definition of Agile? That question probably reveals why they want to be Agile... With the usual answer being... To be more competitive in getting products to market! Shorter lead times, more transparency.....

So if you're a company, organisation or team that wants to move to being Agile... What would your vision statement look like? That one-liner or paragraph that describes your Agile utopian vision?

I think mine would probably look something like this:-

"A lifelong commitment to becoming a learning organisation, Where we continually review and refine our methods of working at all levels based on evidence and feedback. 

Where decision-making is visible, genuinely collaborative and encouraged" 

So no mention of standups, planning sessions, user stories or even poker! But a commitment to learn and improve based on what works and what doesn't!

So now it's your turn... What is Agile?























Powered by Blogger.

Follow by Email

Christian Miles

Christian Miles
Passionate, Self motivated Scrum Master, Well versed in agile methodologies, Agile adoption & transformational change - I love sharing my experience of the agile world with others, Either to ease the transition between traditional waterfall methodologies to Scrum/Kanban or just to help teams work more collaboratively.... Also a big lover and over user of the exclamation mark!!!!!!!

Translate

About Christian Miles

My photo


IT specialist with over 15 years extensive commercial experience and a proven record of designing, developing and delivering for many tier 1 clients. Strong customer facing experience and an advocate of delivering cost effective, common sense solutions.

Well versed in agile methodologies I'm happy to share my experience's with you and your teams either to ease the transition between traditional waterfall (prince 2) methodologies to Scrum or Kanban or just help teams work more collaboratively.... I'm a Certified Scrum Master a member of the Scrum Alliance and regular blogger and Tweeter on all things agile!

Please feel free to connect to me - I'm always interested in expanding my network and discussing new opportunities.

Contact Me

Name

Email *

Message *

Search Bar