Category Archives: Agile

From Factory to Labs – is that the better metaphor?

As you probably know this blog was partly inspired by my frustration with managers and leadership who compared IT delivery with factories. This year at Agile Australia I was very positively surprised that the topic of the factory metaphor came up in a few talks. I am really glad we finally talk about the problems that stem from management using manufacturing thinking for IT delivery. Given I have spoken about this before I don’t want revisit the reasons here and rather spend a bit of time on an alternative model that was put forward at the conference by Dom Price from Atlassian – it’s not a factory it’s a lab.

Look at this slide from the talk for a summary of why the Labs model is more appropriate.

2017-06-23 14.20.51

There is a lot I like about the Labs metaphor that could inspire better management – the inherent uncertainty around IT delivery, the data driven nature supported by the scientific method, building in failure as a normal occurrence for which we try to minimise the impact instead of assuming we could prevent it. That being said, I feel the Labs model might be taking it perhaps a step too far as there is a level of predictability that is required by management and by business stakeholders. A delivery roadmap highlighting features to be delivered is often underpinning the business case. I might be too far away from scientific labs and the right examples might exist, but it is my impression that those roadmaps are less common in labs than we would want in IT. My experience with labs has been that timelines are full of unknowns, more than we would accept in IT delivery.

At this point there are three mental models that I am aware of, the factory, the design studio and the lab. I believe the first one is the dangerous one to use as inspiration for management principles, for the last two I am hopeful that combined it might make for the right inspiration for management going forward. I have to think a bit more about this on the back of Agile Australia. Stay tuned as I will be coming back to this topic.

6 Questions to Test whether You are Working with your System Integrator in a DevOps way

anger-1226157_1280If you have been following my blog, you will know that I am disappointed on how little the cultural relationship between companies and their systems integrators is being discussed in blogs, articles and conference talks. As I am working for an SI I find this surprising. Most large organisations work with Sis, so why are we not talking about it? If we are serious about DevOps we should also have a DevOps culture with our SIs, shouldn’t we?

When I speak to CIOs and have a discussion about DevOps and how to improve going forward, I often get a comment at some stage – “Mirco you seem to get this. Why is it then that not all projects with your company leverage the principles you talk about?”.

A good question, and one that a few years ago I didn’t have an answer to and hence made me a bit unsure on how to answer. I have spent a lot of time analyzing in the years since. And the truth is, that often the relationship does not allow us to work in the way most of us would like to work.

The other week I had a workshop with lawyers from both my company and lawyers from a firm that represents our clients to discuss the best way to structure contracts. Finally we all seem to understand that there is a lot of room for improvement. We need to do more of this so that we can create constructs that work for all parties. I am looking forward to continue working them – and how often do you hear someone say that about lawyers 😉

Coming back from yet another conference where this topic was suspiciously absent, I thought I write down this checklist for you to test whether you have the right engagement culture with your system integrator that enables working to the benefit of both organisations:

  • Are you using average daily rate (ADR) as indicator of productivity, value for money, etc.?
    +1 if you said No. You can read more here as to why ADR is a really bad measure all things being equal.
  • Do have a mechanism in place that allows your SI to share benefits with you when they improve through automation or other practices?
    +1 if you said Yes. You cant really expect the SI to invest in new practices if there is no upside for them. And yes there is the “morally right thing to do” argument, but let’s be fair, we all have economic targets and not discussing this with your SI to find a mutually agreeable answer is just making it a bit a too easy for yourself I think.
  • Do you give your SI the “wiggle room” to improve and experiment and do you manage the process together?
    +1 if you said Yes. You want to know how much time the SI spends on improving things, on experimenting with new tools or practices. If they have just enough budget from you to do exactly what you ask them to do, then start asking for this innovation budget and manage it with them.
  • Do you celebrate or at least acknowledge failure of experiments?
    +1 if you said Yes. If you have innovation budget, are you okay when the SI comes back and one of the improvements didn’t work? Or are you just accepting successful experiments? I think you see which answer aligns with a DevOps culture.
  • Do you know what success looks like for your SI?
    +1 if you said Yes. Understanding what the goals are that your SI needs to achieve is important. Not just financially but also for the people that work for the SI. Career progression and other aspects of HR should be aligned to make the relationship successful.
  • Do you deal with your SI directly?
    +1 if you said Yes. If there is another party like your procurement team or an external party involved then it’s likely that messages get misunderstood. And there is no guarantee the procurement teams know the best practices for DevOps vendor management. Are you discussing any potential hindrance in the contracting space directly with your SI counterpart?

A lot is being said about moving from vendor relationship to partnerships in the DevOps world. I hope this little self-test helped you find a few things you can work on with your systems integrator. I am living on the other side and often have to be creative to do the right thing for my customers. It is encouraging to me to see that many companies are at least aware of these challenges. If we can have open discussions about the items above, we will accelerate the adoption of DevOps together. I promise on the side of the SIs you will find partners that want to go the way with you. Find the right partner, be open about the aspects I described above and identify a common strategy going forward. I am looking forward to this journey together. Let’s go!

How to Structure Agile Contracts with System Integrators

As you know I work for a Systems Integrator and spend a lot of my time responding to proposals for projects. I am also spending time as consultant with CIOs and IT leadership to help them define strategies and guide DevOps/Agile transformations. An important part is to define successful partnerships.  When you look around it is quite difficult to find guidance on how to structure the relationships between vendor and company better. In this post I want to provide three things to look out for when engaging a systems integrator or other IT delivery partner. Engagements should consider these elements to come to a mutually beneficial commercial construct.

Focus on Dayrates is dangerous

We all know that more automation is better, why is it then that many companies evaluate the ‘productivity’ of a vendor by their dayrates. Normally organisations are roughly organised in a pyramide shape (but the model will work for other structures as well).

It is quite easy to do the math when it comes to more automation. If we automate activities they are usually either low skilled or at least highly repeatable activities which are usually performed by people with lower costs to the company. If we automate more tasks that means our ‘pyramid’ becomes smaller at the bottom. What does this do to the average dayrate? Well of course it brings it up. The overall cost goes down but the average dayrate goes up.

pyramid

You should therefore look for contracts that work on overall cost not dayrates. A drive for lower dayrates incentives manual activities rather than automation. Besides dayrates it is also beneficial to incentivise automation even further by sharing the upside of automation (e.g. gain sharing on savings from automation, so that the vendor makes automation investments by themselves)

Deliverables are overvalued

To this date many organisations structure contracts around deliverables. This is not in line with modern delivery. In Agile or iterative projects we are potentially never fully done with a deliverable and certainly shouldn’t encourage payments for things like design documents. We should focus on the functionality that is going live (and is documented) and should structure the release schedule so that frequent releases coincide with regular payments for the vendor. There are many ways to ‘measure’ functionality that goes live like story points, value points, function points etc. Each of them better than deliverable based payments.

Here is an example payment schedule:

  • We have 300 story points to be delivered in 3 iterations and 1 release to production. 1000$ total price
  • 10%/40%/30%/20% Payment schedule (First payment at kick-off, second one as stories are done in iterations, third one is once stories are releases to production, last payment after a short period of warranty)
  • 10% = 100$ on Signing contract
  • Iteration 1 (50 pts done): 50/300 *0.4 * 1000 = 66$
  • Iteration 2 (100 pts done): 100/300 * 0.4 * 1000 = 133$
  • Iteration 3 (150 pts done): 150/300 * 0.4 * 1000 = 201$
  • Hardening & Go-live: 30% = 300$
  • Warranty complete: 20% = 200$

BlackBox development is a thing of the past

In the past it was a quality of a vendor to take care of things for you in more or less a “blackbox” model. That means you trusted them to use their methodology, their tools and their premises to deliver a solution for you. Nowadays understanding your systems and your business well is an important factor for remaining relevant in the market. Therefore you should ask your vendor to work closely with people in your company so that you can keep key intellectual property in house and bring the best from both parties together, your business knowledge and the knowledge of your application architecture with the delivery capabilities of the systems integrator. A strong partner will be able to help you deliver beyond your internal capability and should be able to do so in a transparent fashion. It will also reduce your risk of nasty surprises. And last but not least in Agile one of the most important things for the delivery team is to work closely with business. That is just not possible if vendor and company are not working together closely and transparently. A contract should reflect the commitment from both sides to work together as it relates to making people, technology and premises available to each other.

One caveat to this guidance is that for applications that are due for retirement you can opt for a more traditional contractual model, but for systems critical to your business you should be strategic about choosing your delivery partner in line with the above.

I already posted some related posts in the past, feel free to read further on:

https://notafactoryanymore.com/2014/10/27/devops-and-outsourcing-are-we-ready-for-this-a-view-from-both-sides/

https://notafactoryanymore.com/2015/01/30/working-with-sis-in-a-devopsagile-delivery-model/

https://notafactoryanymore.com/2015/02/26/agile-reporting-at-the-enterprise-level-part-2-measuring-productivity/

Agile Governance – A short overview

I recently ran a seminar on Agile governance, so what does this even mean? Agile governance requires you to find the right balance between the complete chaos of no governance at all and the smothering of all Agile benefits in overbearing governance. In this article I want to provide an overview on Agile governance across a few levels: Transformation, Program, Project and team level. There is a lot more to be said than I can put into this post, so expect me to come back to this over time.

Agile Transformation governance

To borrow from Lord of the Rings “One does not simply transform an organisation to Agile”. At the transformation level it is important to provide support for teams as they encounter challenges for adopting Agile. Some problems can proactively be addressed like training, coaching and enable good engineering/DevOps practices. Others will be uncovered as you start down the adoption path. Those blockers can be identified from the retrospectives at the team level as well as by speaking to Iteration managers and coaches. These blockers should be prioritised and provide the transformation backlog to address at organisational level. I find the below transformation governance structure very helpful as a starting point:

agile governance

 

Agile governance at the program/project level

I have shared my view on how to manage at the program level before here. Just one additional word of warning: Do not try to compare teams against each other for performance measurements, even under the guise of gamification this really can only lead you to bad development patterns. There are teams where this works and where their leaderships does not use the information for the wrong reasons, but the risks are higher than the benefits. Defining the success criteria for each team individually is a much better way to deal with this.

Agile governance at the team level

At the team level the SCRUM methodology provides a set of useful governance elements which you should leverage, adopt and adapt:

  • Sprint Reviews
  • Sprint Planning
  • Retrospectives
  • Team based estimations

Additionally you can use Agile maturity models and Agile metrics for teams to evaluate themselves and their progress in maturing their Agile practices.  Good coaches can help teams in this evaluation without being judgmental.

A comment on measuring individual productivity:
How do you measure the productivity of team members in your Agile teams? The short answer is YOU DON’T. I have talked about productivity in this post and if you don’t believe me perhaps Dilbert can help you understand how poisonous this idea is for your teams:

dilbert2

 

I am looking forward to hear from the community what you use to govern your Agile adoption across the different levels.

Thoughts on the 10th State of Agile Survey

adopt

10th Agile reportJust recently I reviewed the 9th Agile survey (read about it here) and already the 10th version is out (you can access the survey here), so I thought I provide an update. Given the results are not that different from the previous year, I will write this post a bit different. I will review some of the key results and then will provide in a second section some critical thoughts on the survey.

Part 1 – Review of the Results

Our delivery world is complex (multi-modal, distributed and outsourced)

Looking at the results about company experience, 53% say that less than half of the teams in the organisation uses Agile, only 9% say that everyone is doing Agile. So clearly we live in multi-modal world. 82% are working with distributed teams, which is larger than I expected but reflects the largely distributed nature of IT projects these days. And nearly 70% use outsourcing for their development projects. This complex environment is normal. I find it interesting how many clients tell me there are “special” because of these characteristics, they clearly are not.

What are typical benefits of Agile?

The report highlights the following three to be the top answers (which have been the same last year):
– 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 6) and cheaper delivery (not in the list at all).

How do you measure the success of Agile?

The answers to this are also stable:
– On-time delivery
– Product Quality
– Customer Satisfaction
Good answers, I think this reflects well what success looks like. I guess these are somehow measurable and provide some success measure for Agile.

How do you scale Agile?

We see a significant jump for SAFe here from 19% to 27% and I am not surprised. It certainly has a lot of momentum in the industry and provides practical guidance that I leverage in my daily work. Other frameworks are really not present (DAD, LESS,…) and have less than 10%.

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, getting help from someone with experience like an Agile consultant and creating an internal support team.

What tools do you use?

Really not much movement here. The previous favourites remain on top: Jira, VersionOne, and TFS.

What makes Agile fail?

Culture has been called out as main reason this year. And it is hard to argue with this. That however is difficult to address directly. The other information is easier to address: lack of experience is the second main reason Agile fails, this means that we should make sure experienced Scrum Masters and coaches support new projects. Lack of management support and lack of support for the cultural shift are next, something we need to work on as an industry. And then a very much addressable one still gets 38% of the votes: Inconsistent agile practices and processes. This we need to fix, I don’t understand how so many people still allow Agile projects to fail because they think Agile is a freeform exercise. At the end of the day there is a project/outcome to be delivered and too many coaches still shy away from that accountability. If you work with Agile coaches make sure they have skin in the game so that they balance learning with delivery responsibility.

Overall I like the results in the report and it is consistent with the previous year which is good to see.

Part 2 – A more critical look at the survey

I like the results of the survey and got some interesting insights, but how valid is the survey? Do I understand the mechanics behind it well enough to use the data?

Let’s look at a few pieces of information that should make us think about the data before blindly quoting it:

  • First of all – who is the sample audience? Clearly the people responding to this have somehow heard about Agile as it is unlikely that others respond to an Agile survey. The people who respond are self-nominating, so they might be more on the extreme ends and feel they have something to contribute. It is not a random sample of people working in IT. This then influence the data to some degree I would think.
  • 1% said that Agile adoption has failed in their organisation. That number seems very low and might be because those people where it has failed are not responding, or it could be because the definition of failing is actually quite difficult to understand. Does failing mean you are completely going back to Waterfall or because you had mostly bad results from Agile. Not sure what my definition would be, so perhaps the lack of definition causes people to not use this value in the survey.
  • Agile techniques used – Now here I really start to struggle with the values and figuring out how this information should help me. Do only people respond to this who use Agile or everyone (even those using Waterfall)? Daily Stand-ups and prioritised backlog seem pretty fundamental to me and other than in rare cases I would expect Agile projects to use these. The numbers seem low on that basis. But wait it gets much worse, only 54% do iteration reviews/showcases, only 45% have devs and testers in the same team. I would argue that if you don’t have those two you are not really Agile – I defined Agile in another blog post as “ONE team delivery an INCREMENT of a product (at least product tested) within ONE iteration”. The problem here is that one cannot relate the info back to the methodology used and hence it becomes difficult to derive insight from this data.
  • Success measures – Velocity is the largest one. I was hoping we got over the velocity race, but clearly it’s still on. The success measures are very contextual and I would caution anyone to use this without thinking. Take for example “Planned vs. Actual stories” – it could be very positive to deliver more stories than planned or even less stories (as long as the most value is delivered). Context is unfortunately king for metrics, so don’t use the information from this survey blindly.

Thoughts on the 9th State of Agile Survey

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

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.