Feeds:
Posts
Comments

Dazzling Dones: Using the Done column more effectively

September 18, 2012 by Renee Troughton

Jvonvoss at Minds.coremedia.com recently did a very interesting blog – A World without Burndowns: The Unified Taskboard. It was an interesting concept – use your done column to replace your burn down chart.

Normally a taskboard will look like this:

 

The done column is just a list of everything that the team has achieved. Colour may be used to denote expedites.

Using Jvonvoss’s advice a standard Iteration Wall would have the Done column split into each day of the Sprint:

 

In this example, whilst on day 9 we know with certainty that we wont get through all the cards within the next two days as we have been consistently achieving 2 cards per day.

 

In the above example knowing whether we would finish all the cards by the end of the Sprint would be harder to work out – but the interesting reason is why. We can very easily see that the daily throughput is spiking up and down a lot. There is a constraint in the system. You would likely be able to see this as well in a Burn Down chart but visually this would pop more for visitors or managers that walk by.

Using Kanban, similar concepts of visualisation within the Done column can be used to track cycle time. In the example above we can see some outliers, but a majority of the cards are being done within three days and expedites are getting done on the same day. Again this won’t necessarily replace other graphs but the transparency is more apparent.

 

 

Lastly, how could you use a wall to track demand over time within the service industry? Cafes commonly print orders on dockets and add them to a backlog of beverages to produce. As the Barista becomes available they take the next priority item in the backlog and begins working on this. Imagine that when done putting the docket up on the wall by the hour that it came through – what would this enable a cafe owner to do? You can see from the above image that the peak time is 8-9 – you would make sure the majority of staff were on at this time, between 12 and 2 you would likely rotate lunch breaks and you might choose to close down earlier than 6 given how few the orders are in that time slot.

What other ways could you think of using the Done column?

Posted in Agile, Agile Practices, Kanban, Scrum | 2 Comments »

Radical Management: A Book Review

September 14, 2012 by Renee Troughton

When I mentioned to some community friends that I was going to be reading Steve Denning’s Radical Management book a number of them looked at me as if I had contracted some form of virus. “Why would you read a dumbed down book on Scrum?” they said.

The answer for me was simple -

  1. Agile, I feel, isn’t an easy concept for Managers to get. I wanted to check the three prominent books on the market that are there to help Managers become Agile in order to see which one I would recommend if I ever had a manager (which admittedly to date I haven’t) one of them asked me for a recommendation.
  2. Because I do feel that it is hard for Managers to get Agile I wanted to see if there were any hints to what I could do differently or on what practices are relevant for Managers.
  3. I really like Steve Denning’s HBR articles. He has a beautiful writing style which I can appreciate for its simplicity and purpose.

Within this book review I won’t be comparing this book to the other two (although I might do then when I review those), instead I want to focus on my thoughts as I read the book.

Firstly, focusing on my third point above I was not disappointed. For the most part I did continue to enjoy Steve’s writing style in this book. Most pages I felt engaged in and whilst the pages didn’t all fly by, certainly up to the end of Chapter 9 they did (from there it does drag on a little).

Secondly, for a manager that has absolutely zero understanding of Agile and has focused for most of their management tenure on traditional command and control methods, either intentionally or not, I feel that this is an excellent book… to start them on the mental journey.

Which brings me into my third point. It tries to give a practical angle of applying it but I couldn’t in all honesty give this book to a Manager and expect them to be able to do the practices effectively. In fact, in a number of instances there is no detail on how to do a practice. So what this book does really well is get Managers to begin to question what they do and how they do it, less so actually enact change. This could be perceived as quite a concern for many but I don’t think it is that big of a deal – the difficulty is in the mindset change and this book does address well why you would want to shift from being a traditional manager to a radical manager. Additionally the book is riddled with references so if you did read this book and wanted to find more than there are a huge number of useful references at the back.

Now for the negative bits (which I don’t feel outweigh the positive):

  1. Some of the examples are poor – they don’t get the message across or they are weak links to the lesson. Steve is a good storyteller, just a few of the stories are duds. The first one in Chapter 10 is an example of a dud, as is the communicating example further in the same chapter. The roles in Chapter 1 also felt disconnected.
  2. The focus is strongly on Scrum. There is little content on Lean and only a sentence or two on Kanban. It would have been nice to have a broader view of being radical aside from Jeff Sutherland’s perspective. I was aware of this prior to reading the book so maybe I was a little more conscious of it than most readers would be. That said, I actually find that non Iterative Agile is an easier concept for Managers to understand.
  3. Iterations. I’m left with a feeling that Steve doesn’t understand what an Iteration is. It seemed to hint more towards an increment rather than an iteration. The examples that he gives on iterations are poor and for a fundamental principle I think it could have been articulated further.
  4. There are some occasional inaccuracies in advice (in my humble opinion) – like the concept that Value Stream Maps would find the phantom traffic jam problem and what defines “divergence” when using Planning Poker.

So it might be early days to know what book to give to a Manager to learn Agile (even if this was not the intent of this book and it’s intent was to be wider in focus), but overall I would give it a 7/10.

Posted in Agile, Book Reviews, Management, Stoos | Leave a Comment »

If a story is a promise for a conversation then…

September 5, 2012 by Renee Troughton

  1. If a story is a promise for a conversation then… an estimate is a promise to potentially get it wrong
  2. If a story is a promise for a conversation then… a retrospective is a promise to follow through on agreed to actions
  3. If a story is a promise for a conversation then… a vision is a promise to make some SMART goals and then re-evaluate if it is achievable
  4. If a story is a promise for a conversation then… an epic is a promise to break it down
  5. If a story is a promise for a conversation then… a minimal viable product is a promise to deliver the smallest amount possible to learn
  6. If a story is a promise for a conversation then… an Iteration is a promise to not introduce change within it
  7. If a story is a promise for a conversation then… a minimal marketable feature is a promise to deliver value as early as possible
  8. If a story is a promise for a conversation then…  you really shouldn’t be writing that 20+ page specification – get up, walk over to the team and start having a conversation!

Posted in Agile, Agile Practices | Leave a Comment »

The purpose of a Scrum Master

September 3, 2012 by Renee Troughton

I have been pondering lately what the purpose of a Scrum Master or Iteration Manager is.

Many believe that it is a 100% full time role. Some are even concerned that there are formal positions springing up for this role.

Here is my stance (and work in progress model) on the role:

The purpose of the Scrum Master role is to create a self autonomous team through the usage of Agile.

  1. It should never be considered a 100% full time role.
  2. It is a transitory role – there to enable a change in the team.
  3. The change is a change from an environment of Command and Control to an environment of autonomy and empowerment.
  4. The goal is to deliver value to customers frequently and regularly through creation of this environment. The goal is not to have a Scrum Master job for life.
  5. They do this through a series of steps.
  6. These steps are based on Situation Leadership with some tweaking:
    • Directive – The Scrum Master is telling the team what to do and how to do it. This is sometimes common when the team is new to Scrum/Agile and are still learning the rulebook.
    • Facilitative and Advisory – The Scrum Master facilitates cadence activities and advises the team on possible options but is not the final say.
    • Cross Facilitative – The Scrum Master engenders an environment where other team members are starting to facilitate the cadence activities. At this stage the Scrum Master is no longer rounding up everyone for the Daily Standups, instead the team self form and remind each other.
    • Coaching and support – The Scrum Master is only there to course correct and even then only does it through team reflection. They don’t advise on options, instead they engender an atmosphere where the team can come up with their own solutions.
    • Double loop learning – The Scrum Master is ready to hand over the team to itself. The team reflect not only on how they are working together but why they are doing practices in a particular way. It is creating an atmosphere of learning transcendence.

So what, you may ask, does a Scrum Master do as their time with the team whittles down? They do what any good team member in a Scrum team should do – they deliver User Stories!

Posted in Agile, Agile Back to Basics, Agile Practices, Culture, Leadership, Scrum | 26 Comments »

7 things I hate about people that don’t know Agile

August 27, 2012 by Renee Troughton

Last week Assembla posted the 7 things they hate about Agile.  Here is my take on their seven things I hate about people that hate Agile:

1) My cultural norms are not your cultural norms

Apparently according to Assembla everyone that does Agile is old.  Damn I have been doing Agile since I was 27. Apparently that means I am old. I hate that cultural norms are flouted as if they apply worldwide. In the southern hemisphere those following Agile are more likely to be under 40 than over 40.

2) see point 1

Assembla says that Agile is stagnated. Again, just because it has in your country doesn’t mean it is a worldwide norm (see last blog). I agree there is a risk that people want to do and not be Agile, but that has nothing to do with stagnation. I have argued many times on this blog that Scrum is stagnant, I won’t dispute that, but Agile !=Scrum. What Assembla is ultimately saying is that people aren’t learning of other approaches other than Scrum. Is it because they don’t want to, because they see little value in anything else or is it ignorance? I don’t know the answer, maybe Assembla does. When I think of this point it makes me ponder on why we replaced Waterfall with Agile in the first place – was it not because Waterfall failed to evolve and address the problem we were having. Where is it written that Agile must or cannot evolve? We are the community. We are the ones that encourage it’s evolution or not.

3) People that don’t value values

Assembla says that the values in the manifesto aren’t applicable. The examples that they provided were all of manufacturing or command and control environments. Last time I looked Agile was being used for knowledge work not manufacturing. Also Agile methods were used in WWII – in war rooms – where knowledge and innovation were critical. I agree that shared goals are important. I agree that if you can deliver your work and not have to talk to a single person (or even a customer) then values are not important, but I don’t know of anyone in software development that can get away with that excuse these days. You have to have values and goals when doing knowledge work. I am not saying the manifesto is perfect, hell I am enjoying the MoreAgile manifesto these days, but that doesn’t mean all values are useless.

4) People who don’t understand how complex it is to change command and control behavioural patterns

Assembla says that they hate the Scrum Master role and believe that SMs don’t do anything and need to get a real job. As someone that spends a lot of their time trying to re-wire behaviour away from command and control to enable environments where teams are empowered and autonomous I find this frankly insulting. We are taught to respect elders as children, to not talk back to authoritarian figures. Throughout our childhood and schooling we are constantly re-enforced with command and control messaging. And yet we know through many studies that empowered and autonomous teams are more productive and innovative. The Scrum Master is there to break down the old patterns and enable the team to do their job without interruptions. This isn’t something that happens overnight, it takes months of re-enforcement for neurological pathways to re-assert themselves to be the prime pathway. Does this mean that a Scrum Master role is full time – no! They will be helping to deliver when they have free time. They are just a normal in the person in the team who has chosen to step up.

5) People who think that Agile means you have to estimate/People who think that Agile means you don’t have to estimate

Assembla says… actually I am not sure if they are for or against estimating from their comments. Estimation really depends on the environment that you are in, the governance and financial models applied to get work started. Ideally work would be incrementally funded. Ideally all work would be broken down into roughly the same size. In this ideal Agile world estimation is not required (assuming you understand your cycle time or throughput of work items over a defined duration). If you don’t live in this ideal world you might need to estimate – at best a rough idea of the size of the project based upon relativity to other similar sized projects, at worst so you know your velocity if using Iterations.

6) People who assume a practice is 100% applicable 100% of the time and that common sense has no place

Assembla says that pairing all the time is not valuable and just to pair reviews. For me pairing for reviews is worst case scenario, it is a lag identification of problems. Would I recommend pairing all of the time – hell no! But if it was complicated business logic or a new architectural framework being implemented then I would recommend upfront pairing.  Pairing is about quality, reducing rework, cross skilling and engagement.

7) People that think just because it is hard that you shouldn’t strive for it

Assembla goes into some points about Scrum and it’s poorly formed ideas. The first is about co-location. I am not sure exactly what problem Assembla has with being in a work environment that is fun (what people don’t enjoy an odd game of Foosball?!?). I agree that co-location is much harder to do these days, but does that mean you shouldn’t strive for it? There are mixed benefits in this field – co-location provides reduced costs to communication (Thomas Allen curve), but conversely co-location decreases engagement (by 0.2% assuming you are instead working from home, still the figure is fairly negligible).

The second point Assembla makes on this is that cross functional teams are unachievable. In large organisations maybe, smaller ones less so, it depends on your environment. Again it doesn’t mean you shouldn’t strive for it. A cross functional team in the long term is more productive. The purpose of a cross functional team isn’t to reserve talent (where did that one come from?).

The third point Assembla makes is in regards to capacity changing weekly. Discipline is hard. Yes unplanned things happen but onboarding/offboarding project team members every week is a severely dysfunctional Agile team and if this is the norm your organisation has serious problems regardless of Agile. This is why most Agile environments are shifting to product rather than project teams – that way the capacity and capability is always there.

The fourth point Assembla makes is that bugs will come up as you work and these impact your ability to deliver to a plan. Again discipline is hard. If you choose to use iterations, then understand your metrics of how much this is impacting you and add it into your planning process. Alternatively use an iterationless method and allow production defects to be handled as expedites. Or even better build quality in and don’t get bugs in production.

Conclusion

If Assembla is changing its developers every week, has bugs as a frequent occurrence found within production environments (hinting at  lack of automated testing coverage and quality testing), has developers incapable of widening their capabilities, teams that are stagnant, old, without values and breathing each day in an innovationless command and control environment I am really not sure that I would give them my business.

And Assembla – if your response to this conclusion is “we don’t use Agile” then I’ll add my #8 hate:

8) People that hate on Agile who don’t even do it.

Posted in Agile, Agile Practices | 23 Comments »

What is Agile?

August 22, 2012 by Renee Troughton

The Agile RevolutionThis is a back to basics post driven from a number of interesting conversations I have had recently.

Firstly here is my personal definition of Agile:

An umbrella term for the toolbox of light-weight methods, practices and techniques that are focused on working smarter, not harder.

So let’s break that quote down.

“An umbrella term” means to me that it is encompassing, or arching loosely over something.

“toolbox” suggests that there are tools within it. Like all good tradies (that’s Australian for tradespeople) they know which is the right tool to apply to the right problem. You won’t use a hammer to tighten up a screw.

“light-weight” I debated whether to use this in the definition or not – primarily because to some extent I believe that Agile requires greater disciple than ever before, then again, you can still be disciplined and have simple tools in your box.

“methods, practices and techniques” Most believe that Agile is just either Scrum or FDD or XP, but you are rarely ever using just one method (or model) by itself and in reality you are likely to pick and choose the methods, models, practices and techniques that apply to both your organisation’s culture, to the system, to the people and to the situation.

For me a practice is a repeated activity – stand-ups are good example of this, as are retrospectives. The line between practice and technique is where it gets really interesting. Let me give two examples:

  1. Prioritise work
  2. Plan your ability to deliver based on facts

So we can prioritise work in many ways – we can prioritise based upon value, based upon risk, based upon both. We can use MoSCoW, High/Medium/Low, we can have ordered lists – the techniques that we use to get to a position whereby we have a prioritised set of work are quite varied.

We can also plan our ability to deliver based on facts in a number of ways – we can pull in an iteration worth of points based upon the velocity of the last iteration, we can measure average cycle time and understand our variations. Again the techniques to get the answers are varied.

In both instances we want to regularly ensure that we are prioritising work and that we are planning (where needed) based upon facts.

In this context it becomes simple to argue that maybe Retrospectives, as an example, are not actually a practice and more a technique. In this mindset the practice would be “Evolve the way you do your work” and the technique would be “Retrospectives”. I could live with that. There are many different formats that retrospectives come in – deltas, sailboat, quadrants, timelines. You can also evolve how you do your work in many other ways.

This then leads to the debate about whether statements like “prioritise work” and “evolve the way you do your work” are more principles than practices. Ultimately, if you are regularly doing something that reaches that outcome in a repeatable way I would say it is a practice. I am happy to debated otherwise on this front.

“working smarter and not harder”  Note what I don’t say in this definition – I don’t say that it is a software development approach. It can be used for software development, and works well for it, even was born from it, but it can be used for more – so why be exclusionary, spread the love! For this reason it isn’t about working software it is about working smarter. For me, working smarter means delivering value to customers in ways that have reduced waste, improved innovation and a very healthy respect for people.

So in conclusion – just to re-iterate, to me Agile does not mean Scrum. Scrum is just one single element of it. I like to think that methods, practices and techniques such as Kanban, Cynefin, Systems Thinking, Lean, Systemic Flow Mapping, etc all have a place in Agile.

Within Australia I have never seen us as an exclusionary crowd. We embrace better ways of working smarter. We like to absorb them into the Agile toolkit we have, a toolkit that should evolve and change over time as we better understand our world and what works and what does not. Most coaches I know don’t teach just one way, they teach a toolbox of ways and often subscribe to the Oath of Non-Allegiance. They have moved on from the Agile Manifesto and begun to embrace the MoreAgile Manifesto.

As always, all comments are welcome but I desperately desire feedback from the Australian Agile community – what do you think: are we embracers of evolutionary Agile or as a community we are stagnant?

Posted in Uncategorized | 25 Comments »

COTS, SaaS and Agile

August 13, 2012 by Renee Troughton

With the rise of more and more organisations moving towards using Software as a Service (SaaS) and Commercial Off The Shelf (COTS) solutions for their product problems there is a gap in understanding about what Agile can offer in this space.

Most believe that Agile firmly just sits with the actual development of the product and stops there. Today, I will be arguing that there is more and will solely focus on the non product development aspects.

To do this I need to delve a little into the procurement process of choosing a product, but keep in mind that each organisation will have it’s own process. What I will describe is just a method, there will be others, but it is one approach.

So to start let’s go back to basics. You don’t just wake up one day and say “Hey let’s use Product X for our flagship Y!”, unless of course someone high up within your organisation got a free trip to a fab place by a vendor who remains nameless.  You likely have a core need for such a product/service. Maybe your existing system is on green screens. Maybe your business has changed so significantly that you current solution isn’t anywhere close to your needs. Whatever is the reason you need to be clear what the problem is you are solving before looking at what could solve it.

Once you understand your problem think about the needs of the product/service. These are your goals not your requirements.

I believe that it may be at this point in time that you first want to entertain the idea of a COTS/SaaS solution. Normally I believe this would be too early but if you are going down the path of not custom building a solution then you are essence entertaining the idea that you may be dramatically changing your business process model. Now, just as a point, I want to clarify that when I am talking about COTS or SaaS I am not talking about Google docs or GMail, I am talking about software that makes a difference to your business on a day to day basis. It could be a new accounting system or a complete HR package solution. In these instances it is likely that you already have a complicated set of business rules that is embedded to your culture. It is likely that the existing product is so tied to behaviour and process that where one ends and where the other begins is no longer understood.

When you choose to use a COTS or SaaS solution you throw away your business process and use the product/service’s process.

It might be important to you to understand the deviation between your current process versus the product/service’s process via a gap analysis so that you can work out the impact from a re-training perspective, but I believe that it is waste – regardless you will have to retrain or hopefully you will chose a solution that is so intuitive your seven year old could use it.

Next you need to understand your desires for the new product/service. These are your detailed desires – but they should not be thought of as requirements as it is highly unlikely that a single product or service will meet all of your desires.

Categorize your desires into three levels – absolutely critical (showstopper if product doesn’t have), would be elated if it had/did, would be nice if it had/did.

Do these sessions in the same way you would do all of your Agile work – in collaborate teams.

Kick-off your procurement process using the categorized desires as feeder items. Rate the products/services based upon these categorized desires. Naturally you will rate them on other procurement factors such as organisational stability, reputation, service levels, etc.

For the three products/services that score the highest on your ratings invite them into a collaborate workshop (not at the same time, separately). Run this in an Agile way and assess how much they are adaptable to the way you are working. Get them to help you break the desires down into real implementable stories. Estimate the stories with their help. Some stories will cost nothing to implement as it will work out of the box, but a lot of the stories will likely require some element of configuration or data gathering and analysis.  When you are estimating consider any interface implications, configuration, customization (strongly not recommended to do this), data gathering, data analysis, legal checks, policy checks and the number of stakeholders that you might need answers from.

Then with the product/service vendor also break down and estimate stories for training, communications, culture and business process change management, deployments, environments and extent of testing. If the provider will be offsite add in additional costs for communication (an additional 10% in accordance with the Thomas Allen curve).

Prioritise all the stories. You can now compare the plans and costs between each of the vendors with an understanding of the cost of the product/service itself. Chose a provider and continue with your procurement process.

When you start to write all these stories up it should become very obvious that implementing a COTS/SaaS solution isn’t as easy or cheap as expected. In fact, it is highly likely that the product/service itself is just 25% of the overall costs. This is something that the people with the buying power often overlook. It is everyone’s responsibility to make sure the real cost comes out and is understood.

Posted in Agile, Agile Elsewhere | Leave a Comment »

« Newer Posts - Older Posts »

Follow

Get every new post delivered to your Inbox.

Join 604 other followers