Tag Archives: agile

Agile needs a more agile mindset – and the end of the Method Wars

Leave a reply

Okay this blog post will be less pragmatic than my usual ones, but I need to get this off my chest. Why do I encounter so many Agilists that are less agile in mind than many of the PMs I know who work on Waterfall projects? Does any of this sound familiar to you and drive you as mad as it does me:

  • “This is not true Agile”
  • “This is not called a User Story it’s a PBI (or vice versa)”
  • “Method X is not Agile, Method Y is much more agile”
  • “Sprints need to be x days long and not any longer”

I have even heard that some methodologies prevent people with their highest trainer certifications from being certified in other methods. I cannot confirm this, but if true it is madness in my view.

This reminds me of all the passion and silliness of this scene from Monthy Python’s Life of Brian:

Let’s make one thing clear: There is no award for being Agile according to any one Agile method. This level of dogma is completely unnecessary and is taking too much energy in Agile discussions.

What we are trying to do is deliver better solutions faster. And all the methods and tools out there are for us to combine to achieve that. Of course when you are not mature you should follow one of the methods more strictly to get used to the new way of working and then later combine it with other elements (Shu Ha Ri is a common concept we use to explain this). We should focus on that. I appreciate that it is often harder to measure outcomes than compliance to a specific method, but it’s worth it.

So if you encounter an Agile coach that is dogmatic or only follows one method and speaks disrespectful of all others, be careful. He might be able to help you a few steps of the journey, but you should look for someone more open minded to help you in the long term.

There are a lot of good talks/articles out there that challenge our “folklore” of software delivery, I find it extremely interesting to read about people who diverge from the “scripture” and do research to prove or disprove what we think we know. A couple of examples:

If you know of more examples, let me know. I love it when concepts get challenged.

Segregation of Duties in a DevOps world

4 Replies

This scene could be from a spy movie: Two people enter the room where release management is coordinated for a major release. The person from the operations team takes out a folded piece of paper, looks at it and types half of the password on the keyboard. Then the person from the development team does the same for the second half and then deployment to production begins. A couple of years ago I was working for a client, where the dev and ops teams had half the password each for production. It was probably the most severe segregation of duties setup I have experienced. The topic of segregation of duties comes up frequently when organisations moving towards using DevOps ways of working. After all how can you have segregation of duties when you are breaking down all the barriers and silos?!?

Let’s explore this together in this post, but first let’s acknowledge a few things: First and foremost, I am not an auditor or lawyer. The approaches below have been accepted to different degrees by organisations I have worked with. Secondly; there are several concerns related to segregation of duties. I will cover the three most common ones that I have encountered and hopefully the principles still can be applied to further aspects accordingly. Let’s dive in!

Segregation of Development and Test

Problem statement: In a cross-functional team wouldn’t the developer “mark his own homework” if testing is done by the same team?!? To avoid this in the traditional waterfall world, a separate testing team performs an “objective” quality control.

Resolution approach: Even in a DevOps or Agile delivery team, more than one person is involved in defining, developing and testing a piece of work. The product owner or her delegate helps define the acceptance criteria. A developer writes the code to fulfill those and a quality engineer writes test automation code to validate the acceptance criteria. Additionally, team members with specific skills like penetration testing or UX test the work as well. And often business users perform additional testing. Agile ceremonies like the sprint demo and the acceptance by the product owner create additional scrutiny by someone other than the developer. In summary, segregation of duties between Dev and Test is achieved as long as people are working well across the team.

Segregation of Development and Release

Problem Statement: A developer should not be able to release software into production without independent quality check to make sure no low quality or malicious software can be deployed. Traditional approaches have the operations or release management team validate quality through inspection and governance.

Resolution approach: In a DevOps world, the teams should be able to deploy to production automatically without any intervention by another team. This is true whether we use traditional continuous delivery or more modern cloud native deployment mechanisms. But how can we create segregation of duties in those release scenarios? We leverage high levels of automated quality controls in modern release mechanisms, which means functionality, security, performance and other aspects of the software are assessed automatically before software is deployed and we can leverage this to create independent assurance. A separate group like a “Platform Engineering” team governs the quality gates of the release mechanisms, the standards for it and the access to it. This team functions as the independent assurance and all changes to the release pipeline are audited. The art here is to get the balance right so that the teams can work independently without relying on the Platform Engineering team for day-to-day changes to the quality gates, while still making sure that the quality gates are effective.

Segregation of Development and Production

Problem Statement: A developer should not be able to make changes to production or see confidential data from production, while a production engineer shouldn’t be able to use his knowledge of production to deploy malicious code that can cause harm. Traditionally access to production and non-production systems are only given to mutually exclusive development and operations teams.

Resolution approach: This is the most complicated of the three scenarios as people should get the best possible data to resolve issues, yet we want to avoid proliferation of confidential data that can lead to exploitation of such data. The mechanisms here are very contextual but the principles are similar across organisations. Give the developers access to “clean” data and logs through a mechanism that masks data. When the masked data is insufficient for analysis and resolution, then escalated access should be provided based on the incident that needs to be resolved. Automated access systems can tie the temporary access escalation to the ticket and remove it automatically once the ticket is resolved. This of course requires good hygiene of tickets as tickets which are open for a long time can create extended periods of escalated access. Contextual analysis is required to identify the exact mechanisms here, but in most organisations masked data should be able to cover most scenarios so that access to confidential data should be very limited. Root access to production systems should be very limited in any case as automation takes over traditional tasks that used to require such access hence the risk is more limited in a DevOps world. And automation also increase the auditability of changes as everything gets logged.

Summary of Segregation of Duties in a DevOps world

Hopefully this gives you a few ideas on how to approach segregation of duties in the DevOps world. Keep in mind that you achieve the best results by bringing the auditors and governance stakeholders to the table early and explore how to make their life better with these approaches as well. This should be a win-win situation, and in my experience it usually is, once you get to the bottom of what is actually the concern to address.

Learning at DevOps speed – How Running a DevOps Simulation can help to change your Culture

1 Reply

A short while ago my team and myself ran a pilot of a DevOps simulation with our friends from G2G3. The idea of learning from a simulation (not unlike business simulations that I used to play as PC games – does anyone remember “oil imperium”?) appealed to me and I set this up for my team.

Let me be honest, I wasn’t sure what to expect. Boy was I in for a treat. Although we had a room full of people who know DevOps principles and practices we learned a lot from this one day. Let me quickly explain how the simulation runs to give you an idea.

The simulation runs in three rounds and in each round you try to make money for the company. The attendees are split into traditional roles like developer, tester, operations, service desk, product owner, scrum master etc. You get precious little guidance and off you go building features and serving customer needs. Not surprisingly you initially struggle. After the first round you talk about what to improve and have another go. And then you do the same for the third round. The real power comes from the activities being non-technical which means everyone can contribute – think of Tetris-style puzzles you have to solve to implement a feature for example. And without worrying too much about specific DevOps practices the team “discovers” better ways of working that are aligned with DevOps principles – collaboration, visual management of work, looking for patterns.

Most of the other DevOps trainings I have been part of have been pretty technical, which is great for the techies among us. But what about the project managers, the defect coordinators, the change management people, the PMO – they either have to sit through some “foreign” material in a DevOps course or often don’t even attend DevOps training. How can we then change the culture of the organisation and be inclusive of everyone. I think this simulation will get us a step closer to everyone understanding what DevOps and Agile is about and that there is a lot that can be done in addition to automation and tech practices.

I believe this simulation can be super powerful if you get your project team or leadership to attend. In a safe environment people can take on roles they don’t usually play and hence emphasize with those roles better after the simulation. The whole team will work on improvements together and it is easy to see how the learnings will bleed into their day-to-day delivery experience. If you leave the training without thinking on how you can use Kanban boards better and how to improve the quality of communication that is associated with your service management tickets I will be very surprised.

The things you experience are the power of simple things like visual management and how to improve processes by looking end-to-end. Everyone in the simulation gets the chance to redesign delivery processes and tools like the ticket system and the Kanban boards. Nothing beats experiential learning and this is the best thing I have seen for DevOps and Agile ideas. We all left the room exhausted from the full-on day, but we also agreed that even though we all knew DevOps and Agile well, we learned a lot from it in regards to practical application. Just imagine how powerful this is with a group of people who have less previous knowledge. I cannot wait to run this again!!! And I cannot wait to run a simulation with our most experienced Delivery people to see how it changes their perspective.

After running the pilot I got a group together to become trainers for this simulation as I have so many ideas on how we can use this to improve organisations and delivery. Of course I want to run this internally as frequently as possible, but I also want to make this available for our clients. If you are intrigued, reach out to me and we can see how we can get something going for you.

  • Solving puzzles aehhh building features
  • The service desk
  • The Development Team
  • Our live dashboard
  • Kicking it off

Thoughts on the 9th State of Agile Survey

1 Reply

State of Agile 9The 9th Annual State of Agile report had some confirming and some surprising results. If you have not read it, it is worthwhile having a look here. And yes I know that number 10 is soon coming out, but hey there is still value in the 9th one to look at. Besides the usual statistics around how much Agile people are doing ( key number for me was only 5% working for fully traditional organisations), it provided some interesting answers to some of the more common questions that I hear and the answers are often not surprising but there was the odd surprise. Let’s jump in:

What are typical benefits of Agile?

The report highlights the following three to be the top answers (which have been stable over the last few years):
– Ability to manage changing priorities
– Team productivity
– Project visibility

This sits well with me as the usual suspects that we have to debunk are not in this list, e.g. faster time to market (only on rank 7) and cheaper delivery (not in the list at all).

How do you measure the success of Agile?

Uhhh, tricky one this one. I have heard the question many times and honestly have struggled to give an answer that satisfies senior stakeholders. So what did the report say:
– On-time delivery
– Product Quality
– Customer Satisfaction

Good answers, I think this reflects well what success looks like. Interesting that some of the items mentioned under top benefits are showing up much lower here: Managing priorities obviously speaks to the product quality and customer satisfaction. But team productivity (29% measure it) and visibility (30% measure it) are much lower on the list. An open question for me is how people would measure productivity in the first place (see my other blog on this).

How do you scale Agile?

As much as I come across SAFe it is only used by 19% of the respondents with all the other ones even lower (DAD, LESS). The largest proportion just uses Scrum of Scrums or some custom created method.

Of the top 5 tips for Scaling Agile at least two are in my top lessons learned too: Consistent process & practices and Implementation of a common tool across teams. I agree with the other 3 tips as well: Executive Sponsorship, having a coach and creating an internal support team.

What tools and practices do you use?

Wow – I was surprised, but perhaps I should not have been that Excel and Project are the most used tools…seriously, are we not better than that??? Oh well on the real Agile tools, Jira and VersionOne takes the cake, with TFS close behind. IBM is much much lower. This represents my position as well, JIRA is certainly the one most used and few people complain about it, especially when integrated with Confluence.

There is also information on the practices uses and I was shocked to see that only 69% use retrospectives and 48% have a dedicated product owner. Overall the adoption rates of the practices feels very low, perhaps there is some fundamental flaw in the data if it considers people who run Waterfall projects but use a select few Agile practices…hmmm….

What makes Agile fail?

Good information here as well, lack of experience is the main reason Agile fails, this means that we should make sure experienced Scrum Masters and coaches support new projects. Lack of management support and a non-aligned company culture are the other two main reasons Agile fails. Those are a bit more difficult to tackle but are important to be aware of as you set off on an Agile project.

Overall I like the results in the report and it certainly helps to see some market data validating points that I keep making with my clients.

Have we Agilists misused the military as example of Command & Control

4 Replies

Washington_Crossing_the_Delaware_by_Emanuel_Leutze,_MMA-NYC,_1851 (1024x656)If you are like me you believed since early days in your life, that the military is the example for command and control. I personally have never experienced the military by myself, but frequently I heard phrases like “We are not as strict with our command and control as the military”. Only recently after hearing from Don Reinertsen and Mark Horstman about their experiences in the military did I come to question my understanding.

“No plan survives the contact with the enemy” – from Helmuth von Moltke the Elder

So in my head I had this organisation where everything is well planned and if anything I would have associated it with the “waterfall” mentality more than an “agile” mentality. But let’s look a bit closer. In any real combat situation the enemy will behave differently to what you expect and it is very unreasonable to account for all possible details in the field. The above quote from von Moltke the Elder demonstrates that. So clearly the planning in detail and then just executing the plan approach will not work in such cases. So how does the military then operate?

The military makes sure that the soldiers understand what the goal of the mission is. Planning is being done on a high level (which mountain to take or what strategic points to take) which then breaks down into more detailed plans and not just for one scenarios. When practicing some variables get changed so that the soldiers learn to improvise and replan as more information about the situation becomes available. Does this sound familiar? It sounds exactly like the behaviour of an Agile team (with the difference that Agile teams don’t get the chance to practice their projects many times before doing it for real).

What this allows is a high-speed of decision while still adhering to a high level plan. It is possible because the organisation is aligned on the goals and high level plan. Imagine soldiers always had to wait in the field until the “project plan” is updated before they can proceed with changes to the plan. That would take way too long, so they are empowered to change as required within certain well-known parameters. By pushing decisions down to the lowest level the speed of decisions improves. And with clear parameters of what they can decide and what not, the risk of these decision is adjustable. When the lower level decisions aggregate to changes to the overall plan, then there are people at this level who can make those decisions as well (the product owners and release train engineers I guess).

I certainly think differently about the military now after hearing stories and examples that show how inherently agile they have to be. It makes for a good organisational example of combining high level plans and goals with agility and how to achieve positive results.

Here is a slide from Don’s talk with a few additional points:

military

I am no expert in the military so I am looking forward to your thoughts and I will surely learn from the discussion.

Impressions from YOW15

Leave a reply

YOWFirst of all, this was my first YOW conference and I have to say that I was impressed. I have not been to a conference with such a high density of great talks. I think the reason this is the case is that this conference covers a wide variety of topics while other more narrow conference like an Agile or DevOps conference have it much harder to avoid a level of repetition.

Rather than talking about a theme let me dive into the talks I attended and my takeaways from each:

Don Reinertsen on Options Theory and Agile
I will be honest I bought a ticket to YOW15 because I wanted to see Don Reinertsen talk – you might have seen my previous blog post about how impactful his ideas are for me. And this talk did not disappoint – I have at least material for four blog posts from it; things I need to rewatch, explore further and build on in my head. But here are a few glimpses of what you can learn from this talk:
How options theory explains the benefit of Agile, Why speed is so important now and becomes ever more important, how the military org-culture is misunderstood Military and how it’s not the command and control we keep hearing about.

Keynote by Adrian Cockcroft
Every talk I hear from Adrian reminds of all the important things we still have to do to build corporate cultures that truly support employees to deal with complexity. And I loved the anecdote about kids believing that the TV is broken because you cannot swipe them like an iPhone. His point that Netflix is not that much better because it has better developer but rather that those same developers used to work in other organisation where they couldn’t thrive should make us all pause and reflect on whether we really do the right things to support our employees.

Randy Shoup on Microservices
I have sat in many microservices talks, but Randy’s has been the most practical. When his slides are available I will use them as reference. Absolutely great. Clear guidance on when and where to use microservices in a very practical environment. For many of us we will likely not re-architect our applications, but find areas where they can benefit us. Look out for his slides and the recording.

Craig Smith on Agile methods
Fantastic overview of all kinds of Agile methods. I think everyone in Agile should watch this once a year to remind himself of the methods out there and how what we now consider to be in the canon of Agile has come from many different forefathers.

James Lewis on Microservices
If Randy’s talk was about the when and where, James spoke about the how. He reiterated how important it is for microservices to have mature development practices in Continuous Delivery otherwise you will fail. He made a case to remove some of the layers of testing by architecting the service right and do the final validation in production. Very interesting thought. And as far as architectural guidance go the Discworld anecdote about the family axe is a great way to explain to architects how microservices need to be constructed to replace all elements eventually and repeatedly.
The Diskworld anecdote: “This, milord, is my family’s axe. We have owned it for almost nine hundred years, see. Of course, sometimes it needed a new blade. And sometimes it has required a new handle, new designs on the metalwork, a little refreshing of the ornamentation . . . but is this not the nine hundred-year-old axe of my family? And because it has changed gently over time, it is still a pretty good axe, y’know. Pretty good.”

Jon Williams on Virtual teams
Working in complete virtual teams is not something we usually do. Jon defined what it means and how you can make it work. While I don’t think I will be in a real virtual team soon, I will surely look up the virtual team building tools he mentioned after I get a chance to watch the replay and write down the names.

Kathleen Fisher on Security
A perspective of security and how insecure our systems are. You keep hearing about vulnerabilities here and there but she brought it to life. I used to work with model checkers back in university and have not used it since. I am glad to hear they are making a real impact these days and might be one piece of the answer to an ever more complex world as the internet of things grows into our lifes.

Dan North on Organisational structure
Perhaps not the most practical talk yet – Dan mentioned he still working on it and some of the ideas require adaption advice. His skills register is however immediately useful to use someone’s self assessment and aspiration to guide the allocation to project teams. Very interesting. Challenging the common principle of persistent teams was another aspect that I need to think about a bit more to see whether I agree or not. I guess I will watch this one on replay as well. And he put one more piece in my puzzle – the adjustment of the return on investment adjusted by risk. Here is a way to try to quantify benefits of Agile and DevOps.

Dave Thomas on Agile is dead
Dave used a controversial title “Agile is dead” to reflect on the state of the industry and how we use the noun “Agile” often to sell something, while we should really use the adjective “agile” to learn how to incrementally do things better. As a consultant myself I am always torn between the ideal principle that Dave describes and which I really like and the reality I see where clients require some more concrete help. Nevertheless listening to him was a great reflection point to challenge myself on some of my beliefs.

Matt Callanan on the Wotif DevOps transformation
This was a great showcase of a DevOps transformation. Of course the practices are known and the complexities of any DevOps journey are contextual but his presentation sparked some ideas in my head that I will explore more going forward. His simple model of getting agreement across the organisation on standards and principles and then making it easy to follow them was something I really like. The automation of standards was another aspect that I hadn’t thought about before and I also liked the use of semantic versioning for the standards.

What a great conference, I will surely be back next year. Thanks goes out to the team behind the conference! Absolutely brilliant work!

Let’s burn the software factory to the ground – and from their ashes software studios shall rise

8 Replies

torchInspired by recent events I thought it is time to revisit the premise of my private blog (“Not a Factory Anymore”). I have recently heard of the first delivery centers being called studios and as you can imagine I was happy to hear the word studio rather than factory (Link). So I thought it’s time for an update on my pet peeve by adding supporting arguments.

First of all, before you continue reading you should read Don Reinertsen’s HBR article (https://hbr.org/2012/05/six-myths-of-product-development ) who makes a brilliant case on why manufacturing is the wrong analogy for product development (and IT development ultimately is product development). He calls out that the misconception of product development as being similar to manufacturing causes a lot of problems for organisations. I will provide my thoughts on some aspects of his article where I feel I can add value, but if you only have a few minutes and have to choose, then read his article and not my blog post (no seriously – go read his article!) – his article blew me away when I first read it and I am sharing it with every IT executive I come across.

“Product development is profoundly different to manufacturing” – Don Reinertsen

There is so much to say about this article, I could write for hours about it, but I will focus on two aspects that I want to point your attention towards because the application to IT might not be as straight forward. Both having to do with batch sizes (and batch sizes is the secret ingredient to any Agile or DevOps adoption):

Firstly the optimal batch size is determined by the holding cost (driving smaller batch sizes) and transaction costs (driving larger batch sizes). In IT the holding costs are a combination of the increasing cost of fixing a problem later in the lifecycle and the missed benefit of functionality ready but not in production. These two factors don’t change much with DevOps. What changes are the transaction costs. Deployments, Testing efforts and migration to production are all aspects that DevOps has made cheaper through automation and through using the “minimum viable process” for governance. This means that the new batch size is much smaller than before. The relationship between DevOps maturity and batch size is something that I hope people start to appreciate more.

 “DevOps is not about making IT efficient, it’s about making business effective through IT.” – Mark Rendell

The second fantastic point that Don makes, which I want to elaborate on, is about effectiveness and efficiency in the context of quality – the smaller batch sizes at fast speed might cause more defects, but these are fixed faster and the learning from it leads to a better overall outcome. As I said in many other places defects are not a bad thing as long as you find them as early as possible and use them to learn. Driving down defects is not an outcome its a side effect of better DevOps practices. With the words of a colleague of mine: “DevOps is not about making IT efficient, it’s about making business effective through IT.”

The second publication that filled me with optimism that we can bury the factory analogy soon is Gary Gruver’s “Leading the Transformation” (http://itrevolution.com/books/leading-the-transformation/ ). He also calls out that executives have to accept the fundamental difference in complexity between IT work and manufacturing. Assuming that you can plan up-front and manage IT with the same tools as manufacturing leads to inappropriate behaviors. Especially his guidance on embarking on DevOps transformations is very valuable and provides a realistic experience.

“Executives need to understand that managing software and the planning process in the same way that they manage everything else in their organization is not the most effective approach. (…) First, each new software project is new and unique, so there is a higher degree of uncertainty in the planning.” – Gary Gruver

After reading Don’s article and Gary’s book – can any executive still argue that the principles of manufacturing still applies? Do we need more evidence? Cultural change is hard and takes a long time. But hopefully the IT industry will soon be filled with application studios full of skilled, creative and motivated knowledge workers and not with factories where each developer and tester is just a cog in the machine…thank you Don and Gary for putting a satisfied smile on my face while reading your publications. I have the torch in my hands and you have given me fire – lets burn those factories down… (in a figurative sense of course)

Picture: Hawaii – by Dan Tentler (Creative Commons License)

The Testing Centre of Excellence is dead, Long Live the Centre of Quality Engineering

1 Reply

“Big, centralised Test Centres of Excellence are a thing of the past” – Forrester 2013

Agile clearly took the IT industry by storm. In my early days trying to bring Agile to projects a few years back I had to explain even what Agile means. Nowadays pretty much all my clients are using some kind of Agile somewhere in their organisation. Now we see the challenges of hot to support delivery in an Agile fashion and how to optimise for speed to market. One common obstacle is duration and effort for testing. Too many organisations are still relying on large scale manual inspection instead of having an optimised and automated approach to testing. Of course in most cases not everything can be automated, but it is far more common to see too little automation than to see too much automation.

“Quality comes not from inspection, but from improvement of the production process.“ – Dr W. Edward Deming

TCOE1The above picture illustrates the shift that is required to really support speed to market. Quality needs to be built into the development process from the beginning and every opportunity for early feedback should be used to avoid the late detection from manual inspection. There is so much good evidence showing that the temporal delay for finding defects is very costly. People don’t necessarily still remember what exactly they were thinking when they made a specific change a few weeks ago. Or worse the fix might even be given to someone completely different who first has to understand the context of the piece of code that he is trying to fix.

For many organisation this provides a challenge as most testing is organised centrally from a Testing Center of Excellence. This needs to change.

TCOE2Rather than having this large group of testers who are centrally organised, we need people with quality focus embedded in our Agile teams. The manual tester who just executes test scripts is a thing of the past mostly. The new roles require people who understand the business context and can come up with test strategies that minimise the risk in our application. Those test experts are the kind of people who look both ways on a one way street, they just think differently to other people and hence have a very specific mindset that we need.

“Good testers are the kind of people who look both ways before crossing a one-way street”

Besides creating test strategies they will also look after exploratory testing which finds things outside of the usual boundaries. And then we need the test automation developers who should also be embedded in the Agile teams. This decentralising of quality experts does not mean that there is no need for a central function. Test Automation requires a technical framework that should be owned by the central function. Additionally the central function should make sure that lessons learned and other experiences are being shared and that the profession of Automation Developers and Test strategists and Exploratory Testers continue to evolve. Providing networking opportunities, knowledge sharing session and more formal guidance on how to embed quality as early as possible in the development process should be the new focus. This also means to collaborate with the development and engineering teams on coding standards, on the way static code analysis is being used and what can be covered by automated unit testing. On the most basic level it is a shift from testing to quality engineering.

The nature of the central function will shift from a Testing Center of Excellence to a Center of Quality Engineering. Will this be difficult and transformation? Yes it will be and I will leave you with this thought that all TCOE practitioners (and testers for that matter) should take to heart:

“It is not necessary to change. Survival is not mandatory.“ – Dr. W. Edward Deming

A personal DevOps Journey or A Never-Ending Journey to Mastery

1 Reply

I spent the last few days at a technical workshop where I spoke about Agile and DevOps and while preparing my talks I did a bit of reflection. What I realised is that my story towards my current level of understanding might be a good illustration of the challenges and solutions we have come up with so far. Of course everyone’s story differs, but this is mine and sharing it with the community might help some people who are on the journey with me.

As a picture speaks more than a thousand words, here is the visual I will use to describe my journey.
(Note: The Y-axis shows success or as I like to call it the “chance of getting home on time”, the X-axis is the timeline of my career)

Personal Journey

The Waterfall Phase – a.k.a. the Recipe Book

When I joined the workforce from university and after doing some research into compilers, self-driving cars and other fascinating topics that I was allowed to explore in the IBM research labs, I was immediately thrown into project work. And of course as was custom I went to corporate training and learned about our waterfall method and the associated process and templates. I was amazed, project work seemed so simple. I got the methodology, processes and templates and all I have to do was following them. I set out to master this methodology and initial success followed the better I got at it. I had discovered the “recipe book” for success that described exactly how everyone should behave. Clearly I was off to a successful career.

The Agile Phase – a.k.a. A Better Recipe Book

All was well, until I took on a project for which someone else created a project plan that saw the project completed in 12 weeks’ time. I inherited the project plan and Gantt chart and was off to deliver this project. Very quickly it turned out that the requirements were very unclear and that even the customer didn’t know everything that we needed to know to build a successful solution. The initial 4 weeks went by and true to form I communicated 33% completion according to the timeline even though we clearly didn’t make as much progress as we should. Walking out of the status meeting I realised that this could not end well. I setup a more informal catch-up with my stakeholders and told them about the challenge. They agreed and understood the challenge ahead and asked me what to do. Coincidence came to my rescue. On my team we had staffed a contractor who had worked with Agile before and after a series of coffees (and beers for that matter) he had me convinced to try this new methodology. As a German I lived very much up to the stereotype as I found it very hard to let go of my beloved Gantt charts and project plans and the detailed status of percentage complete that I had received from my team every week. Very quickly we got into a rhythm with our stakeholders and delivered increments of the solution every two week. I slowly let go of some of the learned behaviour as waterfall project manager and slowly became a scrum master. The results were incredible, the team culture changed, the client was happier and even though we delivered the complete solution nowhere close to the 12 weeks (in fact it was closer to 12 months), I was convinced that I found a much better “recipe book” than I had before. Clearly if everyone followed this recipe book, project delivery would be much more successful.

The DevOps Phase – a.k.a. the Rediscovery of Tools

And then a bit later another engagement came my way. The client wanted to get faster to market and we had all kind of quality and expectation setting issues. So clearly the Agile “recipe book” would help again. And yes, our first projects were a resounding success and we quickly grew our Agile capability and more and more teams and projects adopted Agile. It however quickly became clear that we could not reduce the time to market as much as we liked and often the Agile “recipe book” created a kind of cargo cult – people stood up in the morning and used post-its and consider themselves successful Agile practitioners. Focusing on the time to market challenge I put a team in place to create the right Agile tooling to support the Agile process through an Agile Lifecycle Management system and introduced DevOps practices (well back then we didn’t call it DevOps yet). The intention was clear, as an engineer I thought we could solve the problem with tools and force people to follow our “recipe book”. Early results were great, we saved a lot of manual effort, tool adoption was going up, and we could derive status from our ALM. In short, my world was fine. I went off to do something different. Then a while later I came back to this project and to my surprise the solution that I put in place earlier had deteriorated. Many of the great things I put in place had disappeared or had changed. I wanted to understand what happened and spent some time investigating. It turned out that the people involved made small decisions along the way that slowly slowly lost sight of the intention of the tooling solution and the methodology we used. No big changes, just a death by a thousand cuts. So how am I going to fix this one…

The Lean Phase – a.k.a. Finally I Understand (or Think I do for Now)

Something that I should have known all along became clearer and clearer to me: Methodology and tools will not change your organisation. They can support it but culture is the important ingredient that was missing. As Drucker says: “Culture eats strategy for breakfast”. It is so very true. But how do you change culture… I am certainly still on this journey and cultural change management is clearly the next frontier for myself. I have quickly learned that I need to teach people the principles behind Agile and DevOps, which includes a elements of Lean, Systems Thinking, Constraint Theory, Product Development Flow and Lean Startup thinking. But how do I really change the culture of an organisation, how do I avoid the old saying that “to change people, you sometimes have to change (read replace) people”. As an engineer I am pretty good with the process, tools and methodology side, but the real challenge seems to lie in the organisational change management and organisational process design. And I wonder whether this is really the last frontier and or will there be a next challenge right after I have mastered this one…

The good news is that many of us are on this journey together, and I am confident that on the back of the great results we achieved with tools and methodology alone, truly great things lie ahead of us still as we master the cultural transformation towards becoming DevOps organisations.

The most Controversial Concept in Agile Delivery – Estimating in Story Points

3 Replies

This blog post is another one of those that I should have written a while ago as the topic of story point based estimation keeps coming up again and again. To really understand why story point based estimation is important for Agile delivery, I think I need to explain the idea behind it.

The purpose of estimates is to get a good idea of how much work needs to be done to achieve a certain outcome. To do that, the estimate should be accurate and reasonably precise. This is where the crux of the problem is: precision. If I’d asked you how long it takes to fly from Sydney to Los Angeles, you would not respond with an estimate that includes minutes and seconds because you know that it is ineffective as it is not precise. The more precise we get in estimates, the more we pretend to be able to do something that we cannot do: work at that level of precision. The other downside of precision is that each level of precision requires more work to be put in the estimation process. I have done many IT projects and can tell you that my estimates for each individual task is off by as much as +/- 100% easily, but in aggregate my estimates are pretty good.

Let’s explore the difference between accuracy and precision a bit further:

accurate vs precise

It should be clear that we care more about accuracy than we care about precision and that is exactly what story points do for me. I am spending just the necessary amount of time estimating to be reasonably accurate without trying to become too precise. The usual Fibonacci sequence (1,2,3,5,8,…) helps to avoid false precision as well. Now, to be honest we could call it 1,2,3,5,8 days and be done with it as that would probably achieve the same outcome as story points. The problem is that for some reason we are a lot more tempted to use the other in between numbers when we talk about days. We are also tempted to equate days of effort with schedule, and most of us can attest that a day of effort is hardly ever done in a day of schedule as we get distracted, multi-task or attend meetings. The story point concept provides us with a nice abstraction that prevents these mental shortcuts and keeps us focused on the relative nature of the estimate.

The other thing that should be obvious is that a day of effort for one person is not the same as a day of effort for another person. More experienced people need less time than more junior people, so any estimate in hours or days is flawed unless you know who will do it. Story points do not suffer from this problem as they are relative to other stories and independent to the person performing the tasks associated with it.

The other nice thing with Agile estimation is that it usually is a lot closer to the often recommended Delphi technique, which asks multiple independent experts to estimate tasks and then aggregate it. Planning poker is a pretty close approximation of the Delphi technique and is therefore much more accurate than estimates done by individuals.

But why do we need a point system at all, why do we not just do relative sizing in t-shirt sizes or something similar. As I have explored in another blogpost (link), teams need a goal line whenever there is a certain outcome to be achieved. The easiest way to do so is by tracking progress on a numerical scale (see Agile reporting post). And if you work in a larger organisation you probably want to have some common currency to be able to measure the throughput (see productivity blog) and be able to swap stories between teams. Here I will go with the guidance that SAFe provides, start with a point being roughly a full day of work and estimate everything else relative to that. On a regular basis bring members of the team together to estimate an example set of stories and use this process to recalibrate the relative understanding of size.

So what if things change? One thing that people are always concerned about is scope creep or inaccurate estimates. For a story by itself I don’t have strong opinions on whether or not you update the size once you realise there is more or less work than expected. However, if you use larger buckets for your initial estimates (e.g. a feature that should roughly take you 100 pts), then I think it is important to measure how many points the stories of that feature actually add up to – if that is different to 100 pts in this case you have some real scope change that will impact your timelines.

To close off, I will provide a few helpful links to other comments/blogs about story points which you can use to learn more about this topic:

http://www.scruminc.com/story-points-why-are-they-better-than/

http://collaboration.csc.ncsu.edu/laurie/Papers/ESEM11_SCRUM_Experience_CameraReady.pdf

http://www.mountaingoatsoftware.com/blog/seeing-how-well-a-teams-story-points-align-from-one-to-eight

https://www.scrum.org/Forums/aft/564

http://www.mlcarey321.com/2013/08/normalized-story-points.html

http://blogs.versionone.com/agile_management/2013/10/14/scalable-agile-estimation-and-normalization-of-story-points-introduction-and-overview-of-the-blog-series-part-1-of-5/