The winding road to DevOps maturity

Leave a reply

curving road

I have noticed a trend in the evolution of teams when it comes to DevOps maturity over the years, which I now call the winding road of maturity. Recently I was using a DevOps model to describe the progress overtime, which I’ve designed a while ago and realised that with the advent of cloud based DevOps I have to update my model. So I thought I’d share my observations and see what other people think. Surprisingly this pattern is seen in a lot of different work environments: Deployment Automation, Test Automation and many others. I will use the deployment automation scenario here but believe me it applies in many other technical aspects as well.

 

Here is my current model, which I have shared with many clients and colleagues over time:

Curve 3Stage 1: “Do it All Manually” – We do everything manually each time. We do all the steps in our checklist for deployments or test or whatever it is that we consider to be our daily job. Not a lot of optimisation at this stage and it feels all very heavy-handed.
Stage 2: “Do the Necessary Manually” – Over time we realise that there are many steps that we can skip if we do a quick impact assessment and based on that assessment only execute the steps that are required (e.g. not redeploying unchanged components or not executing tests for functionality that has not changed). We are now in a world where each deployment looks different based on our assessments – this is difficult if there is a high turnover of resources or if transitioning to newbies as they wouldn’t have the skills/knowledge to do reliable assessments.
Stage 3: “Automate the one way” – Then we discover automation. However, automation of the impact assessments is more complicated than automating one common process, so we go back to running all steps each time. This reduces the effort for deployments but might impact the actual duration.
Stage 4: “Optimise for performance” – Once we have mastered automation we start to look for ways to optimise this. We find ways of identifying only the steps that are required for each activity and dynamically create the automation playbook that gets executed. Now we have reduced effort and are continuing to reduce overall duration as well. We are an optimising organisation based on reliable automation.
1. Stage “Do it All Manually” –

Here is where my story usually ended and I would have said that this is an optimising end-state and that we don’t really move around another curve again. However, I believe that Cloud-based DevOps goes one step further requiring me to update my model accordingly:
Curve 5In this new model we do everything each time again. Let me explain. In the scenario of deployment automation, rather than only making the required incremental changes to an environment we completely instantiate the environment (infrastructure as code). In the scenario of test automation, we create several environments in parallel and run tests in parallel to reduce time rather than basing a subset of tests on an impact assessments. We can afford this luxury now because we have reached a new barrier in my model, which I call the Cloud Barrier.

This update to my model was long overdue to be honest and it just comes to show that when you work with a model for a long time you don’t realise when it is out-dated and you just try to make it fit with reality. Well hopefully my updated model helps to chart out your organisational journey as well. It is possible to short-cut the winding road to maturity but as is the case with cycling up a mountain a short-cut will be much steeper and will require some extra effort. See you on the top of the mountain!

Picture: Hairpin Curve – Wikimedia
License: Creative commons

Manifesto-Mania – thoughts on the Half-Arsed Agile and the Anti-Agile manifesto

2 Replies

I came across the following two websites recently:

http://www.halfarsedagilemanifesto.org/

http://antiagilemanifesto.com/

And as is so often the case, when you have to smile about it, it hits too close to home. So I wanted to provide my perspective on these.

Let’s start with the Anti Agile manifesto (http://antiagilemanifesto.com/) – this one is just plainly ignoring the fact that Agile operates in a different cadence and requires a different structure to achieve it’s outcome. However many organisations do follow some of the points mentioned in this manifesto, where stand-ups turn into status meetings and stories are full use cases. Clearly someone who had to suffer from a bad Agile project put pen to paper here – take this as a sniff test if your Agile project is really agile. It is not if this manifesto is true for you.

The Half-Arsed manifesto (http://www.halfarsedagilemanifesto.org/) is different as it provides the challenges that many project teams are exposed to. It’s the tension between local optimisation of teams and organisation wide requirements. Let’s explore this a bit more in detail.

We have heard about new ways of developing software by
paying consultants and reading Gartner reports. Through
this we have been told to value:

Point taken – the Agile space is full of consultants, but hey so is every other space in IT. Let’s move to the next:

Individuals and interactions over processes and tools
and we have mandatory processes and tools to control how those
individuals (we prefer the term ‘resources’) interact

It is important to acknowledge that unfortunately in large organisations you do have mandatory tools and processes. Some of this you should challenge as an Agile team to get a better outcome (e.g. being allowed to use walls to post things even though it might not be “pretty”). Others are required for the sake of the organisation and should be respected. Imagine you are a senior product owner and each team is using a different tool to manage their sprints. You get pictures, excel sheets, links, etc. from your teams to understand their progress, remember this stakeholder is actually paying for your team and is making decisions about the direction of the company, don’t you want him to spend time doing that rather than digging through lots of different data sources? The term resources is terrible, I don’t think we should call people resource – full stop.

Working software over comprehensive documentation
as long as that software is comprehensively documented

I think this is nitpicking. it really comes down to what comprehensively means. In my view Agile teams need to create all the documentation that is required to use and maintain the software. Documentation that is not required in Agile projects is transition documentation that is required to get someone else to do work (e.g. detailed technical designs), they don’t provide value if the team sits together and/or talks every day.

Customer collaboration over contract negotiation
within the boundaries of strict contracts, of course, and subject to rigorous change control

Oh dear – this one clearly speaks to me. As someone working for a systems integrator I do depend on contracts and change control. I always aim to find a better solution, but there are commercial realities and this point is just try. Let’s find the most creative way to solve our problem while still having the required commercial framework in place.

Responding to change over following a plan
provided a detailed plan is in place to respond to the change, and it is followed precisely

Honestly, I am struggling with this one. Isn’t all of SCRUM based on a plan for how to manage change? And isn’t SCRUM about rigorously following the few mandatory ceremonies (at least until your are experienced enough to know why you are breaking the rules).

That is, while the items on the left sound nice
in theory, we’re an enterprise company, and there’s
no way we’re letting go of the items on the right.

Yes – I am working in the enterprise world. And while everything here is a bit harder, I enjoy the challenge and bit by bit we can hopefully change the environment together. If we only accept the purest of Agile forms, we are making the perfect the enemy of the better. Don’t tell people that they are not Agile, help them get a bit better and a bit more agile.

20 principles for a successful start to a career

1 Reply

adviceThis blog post has been in the making for at least 6 years and will likely be my longest one. Since then I have been gathering my advice for new joiners. Usually someone new who joins the company makes very similar mistakes (of course not everyone is making all of them ;-)), So I thought I share my view of some of the principles to follow with the rest of the organisation. This will probably be kind of long-ish, but I hope it will help some of the new joiners and perhaps even some of the more seasoned professionals as I try to explain the perspective of the supervisor for some of the principles (rest assured a similar post for manager is already in the backlog as well). As with all career advice, please only follow what makes sense to you. This list is meant to provide you a reflection point to consider your behaviour and what would be the most effective for the organisation, not a one size fits all approach. Let’s dive in…

  1. Managerial Economics 101 – I learned this principle from my good friends at www.manager-tools.com and it is probably the most liberating and useful principle to understand. Managerial Economics 101 says that if two people can perform the same task to similar quality, the more junior or less paid person should do that. The idea being that this frees up the other person to do higher value work. What does this mean in practice? As a manager it means you should not feel guilty to delegate to your directs work that is not exciting. Often we feel bad delegating mundane or repetitive tasks, but if you think about this principle you realise why you have to delegate. As a direct looking at this you should do the same from the other side, pick up all the work that your manager is doing that you could do for him, volunteer to write meeting notes or perform routine tasks. Trust me, your manager will love you for it.
  2. Never Be Defensive – If there is a personal trait that can be really irritating, it is defensiveness. It can make any feedback discussion pointless. I suffered from being defensive for a good part of my career and to this day it takes effort not to get into defensive mode when it feels like there are so many good reasons to defend myself. It just never makes things any better, even if it was not your fault. As a manager who deals with someone being defensive, consider using a “shot across the bow”. Give your feedback and then walk away if the other person becomes defensive. Your feedback has only one purpose: To improve future performance. After giving your feedback the other person either performs better (in which case engaging with the defensive behaviour would not have made a difference) or not (in which case you will get a second chance to give the same feedback, this time with more evidence). If you are the direct, whenever you say “…,but…” or “someone else’s fault” step back to reconsider, feedback is a gift given too rarely. Try to find some truth in it and action on it rather than spending your efforts defending yourself, you can always be better, can’t you?
  3. Networking = Giving Freely – When you join an organisation everyone tells you how important it is to network. But what does this mean? My answer is, give freely when someone is looking for help, share material that you think could be of interest, offer to step in when someone needs help. That’s how you network. Your name will get out there as someone helpful and all the positives of network will become available to you, your name will be known and even better, when you need help, others owe you one. That goes a long way. Also look at principle 19 – personal brand.
  4. Every Feedback Form Will Have One Thing You Disagree With – It is my experience that people try to be helpful with their feedback. But sometimes they don’t get it right and that means that usual in feedback forms you will see at least one thing you disagree with. Remember not to be defensive about it, let it go, it’s just one piece of feedback. Focus on the items of feedback that make sense to you and address those. If the same point comes up again however, you should look closer. Perhaps you have just discovered one of your blindspots. And identifying those is worth a lot.
  5. Do Ask Questions – No one expects you to be perfect and especially when you join a new project a lot of the language will sound like from a foreign country. TLAs (Three Letter Akronyms) everywhere. It is always better to ask for clarifications than to be silent and spend a lot of time working it out. The same goes for new processes or other questions, you are excused for asking, you are not excused for misunderstanding or not being able to do your job because you didnt ask. I remember working for a company and trying to figure out a process myself, just to spend hours on something my colleague could do in minutes. I looked like a fool at the end of the day for not asking.
  6. Too Many Blank Questions Make You Look Lazy – In general questions are good, but if you have the opportunity to do research before asking the question, it looks lazy if the answer is one google search away. It is always better to ask questions of clarifications in the form of “Does process x mean I have to do a, b and c” rather than “how does process x work”. Just asking one blank question after the other makes it sound as if you want someone else to do your job.
  7. Communication Is What the Listener Does – It does not matter how much you try, sometimes you will get misunderstood. And it is not the listeners fault, you have to consider it yours and try again in a different way: with a picture, rephrasing it or by describing it from a different perspective. It is all too easy to say I have communicated it to him, if the listener does not understand it. And after all we are measuring outcomes, not intent. So make sure that the listener understood what you said and try to adjust your communication style to the listener. The only one who can fix a situation of misunderstanding is the one who is speaking, the listener cannot help much other than trying to show that he did not understand. And to make things easier for yourself follow BLUF, Bottom Line Up Front – Start with the summary and then give the narrative, it will make it much easier for the other person to understand what you are trying to communicate.
  8. You Can Only Change Yourself – Many times people complain about their colleagues and my answer is always the same, you wont be able to change him or her, but you can change your behaviour. If you want to improve the productivity of the team find out how you can adjust to the others style and hence improve the team. You can give feedback to others, but the only person you can change is yourself and by adjusting your own behaviour you can improve a situation a lot even if the other person does not change.
  9. You Are Responsible For Your Feelings – How many time have I read an email and got angry/disappointed/mad only to step away from it and realise that it is my own reaction to the email and not the intent of the writer. Or you sit in the car and the driver in front of you is driving super slow, he is driving you mad. Wait – he is not driving you mad, he is just driving in his own style, you are driving yourself mad. I have experienced many times that you can choose to get angry or choose to remain calm and the situation will play out accordingly. It is you who is responsible for your feelings, many of us get angry at work, but the best of us don’t show it and the even better ones don’t get angry at all, they choose to remain calm. It’s no excuse to say your colleague made you angry, you always have the choice. My advice: step away, breath in, breath out, move on…
  10. A Task is not Done Until Status is Communicated – If some assigns you a task or delegates something to you, he actually assigns you two things, the task itself and the responsibility to communicate status. At the very least to tell him when you are done. From an organisational perspective the work is not done until someone knows that it has been completed and can act upon it. You are unlikely doing the task for the task’s sake, it is because something else requires the output or someone requires the information, so make sure the completion of the task is communicated. If the tasks will take a long time, even if not asked explicitly for status, communicate the status anyway. If you are on track it will make your supervisor happy to know and make him not worry, if you are not on track early communication will allow him to help you out or at least set expectations that it might get a delayed with other stakeholders.
  11. Admit Mistakes Early – On a related note, admit your mistakes early and openly. It is very unlikely that you will be able to cover up your mistakes. If you are open about it and ready to fix the issue at hand, people will forgive you. The longer you wait and the worse the situation gets. Even worst if someone else takes the hit for you, and later it is discovered it was you, the implications will be much more severe. The ability to admit mistakes and to apologize goes a long way, and a heartfelt apology can be a strong means to build relationships that would otherwise be ruined. Be the better person and apologize first.
  12. You Are Allowed to Make Mistakes, Just Don’t Repeat Them – One of the most influential pieces of advice early in my career was someone telling me this. And they were right: you have to make mistakes to learn, but if you repeat them you will receive negative feedback. After all there is truth to the saying that “Good judgment comes from experience, and you gain experience from bad judgement”. There are a few things to take away from this – a) you should be courageous to try things out, b) you should make sure that if you make a mistake that you understand how to learn from them and avoid them in the future and c) you should keep trying things even if the mistakes hurt. As a supervisor you also need to understand this and allow people to make mistakes and not punish them for a mistake. You should look out for the ones that don’t learn from their mistakes, but the others will improve quickly.
  13. Answer the Question – If someone asks you: “Are you on track with your work?” there are only two possible answers: Yes or No. Anything else is a distraction. The first word out of your mouth needs to be “yes” or “no”. The person asking the question will ignore everything you say until he gets that answer. I myself have the same tendency to try to explain the answer before giving it, but trust me it is a bad habit. I have now learned to think about the answer, give the yes or no and then go on to explain the situation. And don’t try to get away with “Yes and No”. The same by the way is true if someone asks you for a number, the first word out of your mouth should be a number, not “well, let me explain”. This will be difficult initially, but it is very important to be respected and listened to by leaders.
  14. Don’t Be a Film Critic – No one enjoys listening to someone complain. I know everyone needs to vent once in a while, but it is not a very productive behaviour. Try not to vent to your boss or anyone you work with. If you find something to criticise do so in a productive manner and with an idea how to fix it. And honestly the best way is to recommend something you can do to help fix it, otherwise it just feels like a film critic who sits there talking about the movie, but who wouldn’t be able to make a better movie himself.
  15. Do not Be Idle – If you have nothing to do, that is not an excuse for long internet surfing sessions. There is always so much to do and there is likely someone around you who needs help. Reach out, offer help. And if there is no one in need of help, spend the time improving your own or the teams productivity by working on a better template or process. Not having work assigned or being blocked is tempting for a bit of idle time, but it is likely that it will come to haunt you later; either in your performance rating or because you are getting used to it and are less productive later on.
  16. Ownership and Accountability is Different From Actioning – It is always nice to delegate some work to someone else, but let’s be clear: it is still your accountability that it gets done, you still own the task. I personally don’t accept it if someone who I gave a piece of work to later tells me he delegated it and it was that persons fault. You don’t have to do everything yourself and as of principle 1, you shouldn’t. But own up to it and protect those you delegate to, especially if they are your team members. The buck stops with you even if you try to push it to someone else. In that case it is just a double whammy, you didn’t get the work done and you tried to deflect your accountability which makes you look bad.
  17. No One Other Than Yourself is Responsible for the Quality of Your Work – A related point is that you cannot rely on someone else to test your work, it is great if you have other testers or QA people involved to help find problems, but rest assured that you are accountable for your work. At best you will both be in trouble, but just creating something and not checking the quality yourself is not acceptable.
  18. Trust But Verify – The last related principle is that of trust. The speed of trust is amazing, try to micromanage someone and you will quickly notice how time consuming it is, trusting someone makes transactions much faster. There is a but – you need to verify the work when it comes back. You cannot just forward it to your boss without checking. Remember principle 16.
  19. Create Your Personal Brand – The longer you are with an organisation the more important it is to have your personal brand. You should stand for something – the guy who is good at x, or the guy who is passionate about y. There are many different aspects of this: Social media like blogs and yammer let you share your views with the world, working in related areas and doing a good job gets the word out that you know what you are doing, going to community events and conferences and talk to peers about your passion creates your network. All this belongs to creating your brand. If people know what your brand is, you will be surprised how many opportunities turn up on your doorstep.
  20. Be persistent and accept silence – This is my personal favourite and one that I think helped me the most in my career. There are things that I would like to change in my organisation, or on my project or in my community and none of that happens over night. You send emails with improvement ideas to people and often nothing comes of it, there is only silence. But if you are persistent at some stage someone will listen and something will get done. It will take a while, but I do believe each one of us can make a difference if we are persistent, remain positive and constructive with our feedback, and then one person at a time we will make our company, our community and our network of people a better place to be.

Okay this has been a pretty long post, as I said this material has been with me for a while. I encourage you to come back to this post once in a while as I am sure you will find another principle all of a sudden makes sense or it encourages you to try to improve in an area you didn’t have the bandwidth to last time. Getting better never stops…

Picture: Advice by Laughlin Elkind
License: Creative Commons

Can you do Agile development with Packaged Software?

3 Replies

I have heard this question many times and only recently realised that the person asking the question and me hearing the question had a different understanding of what the question means. Let me try to explain. The question posed by this blog post can be interpreted in two ways:

  1. If you use packaged software like SAP or Siebel, can you use an Agile methodology?
  2. If you want to be Agile, can you use packaged software?

questionmarkI know the difference is subtle, but the impact of the understanding and the response is amazing. I had this realisation when talking to a colleague of mine who is training an Agile course with me in the next week. My response to both questions would be yes, the difference being that to the first question I would say “YES”, to the second question I would say “yes, but…” It is easiest to see the difference if you consider the alternatives in question: in the first question the alternatives are Agile or Waterfall, in the second question the alternatives are Packaged Software or Custom Software.

 

Let me explain – If you want to be agile, you have a couple of things you want to achieve, so lets look at some of them when considering packaged software

  • Faster time to market – my experience tells me that you will not be as fast with packaged software as you would be with a custom solution in many cases (just the sheer size of the software is often significantly larger)
  • Decoupling of dependencies – this is much harder in packaged solutions
  • Use a lot of automation and DevOps practices – this is a little bit trickier with packaged software
  • Want a first release quickly – if you know which product to choose you might be, but usually packaged software requires more requirements analysis and fit-gap analysis up front to choose the right product

So if you want to be really Agile and use DevOps practices and autonomous self-directed teams with little dependencies then packaged software might be harder to use, hence the “yes, but…” You should ideally choose a custom solution or perhaps a SAAS solution in that case (but be careful, many SAAS products are not DevOps supportive either).

Now lets look a the other question: Assume you already use Siebel or SAP, can you use an Agile methodology? Here the answer is a loud and clear “YES”. Think about all the good things about Waterfall – they all still exist in Agile just better, if you do it right. You have the rigor of change control (just for a shorter period – the iteration), you have extensive testing (just automated and within the iteration), you have as much or as little time for analysis as your require in the discovery phase. You will likely not see the same results in regards to time to market as if you would use custom software, but I bet you get better results than if you do waterfall with packaged software.

So yes – I think I (and many others) have responded to the wrong question.

To give you an idea about my experience: I have supported Agile projects for Siebel at many different levels of scale and usually with 2-3 week iterations. I have implemented some of the core practices of DevOps around configuration management and automatic deployments for Siebel and we are currently in the process of implementing automated testing as well (hopefully including TDD down the road). It is absolutely possible and I think most of my colleagues would agree that using Agile is preferred over Waterfall for Siebel if you do it right (perhaps packaged software is a little bit less forgiving than custom if you don’t do it right – but that’s for another discussion). Could we be faster and better if we could use a custom solution? – absolutely. But that is a different question now, isn’t it? 😉

Picture: Question Mark by Marco Bellucci
Licence: Creative Commons

The need for an Onshore Technical Apprenticeship model to counter the falling ladder

2 Replies

This post is a little bit different to my other posts, it highlights a challenge that most of us in the western world is facing, now that offshoring and nearshoring is just a reality of life. I think companies need to think about an onshore technical IT apprenticeship program that allows them to build more technical skills onshore. And it does not matter whether you are a consulting company, an IT shop or a manufacturing business, software is an important part of your business and you better keep building the skills required to run it.

When I started working for my current employer over 10 years ago everyone did some kind of technical work as a new joiner, I personally did some Cobol programming, many of my friends worked with Java. Then as we got more and more senior we had a good understanding of what it takes to develop a solution.

Nowadays if you are trying to staff a technical onshore role, it is actually not easy to find people and often you look to colleagues from offshore centres to help out. A lot of project and program management is still being done onshore and many of the current leaders still come from my generation of “Been there, done that”.
Unfortunately in many IT teams onshore it is today more important to learn exactly 3 technical skills: Excel, Powerpoint and MS Project…

ladderA bit of background:
The problem I describe is what I call the “Falling Ladder” or which in a TED talk was called “sinking skill ladder” (around 10:50 into this video http://www.ted.com/talks/nirmalya_kumar_india_s_invisible_entrepreneurs/transcript?language=en#t-698501) – once you have given all the on the ground technical work to delivery centers, you will soon realise that the people onshore do not have the knowledge to design solutions really well, so you start handing over design as well. Soon you don’t have skills to really project manage anymore as all you can do is manage the spreadsheet, so you hand over project management as well. And then soon all there is onshore is the demand creation either through sales externally or internally. And would you trust a Technical Architect who has never seen code? Okay – this is a slight exaggeration, but you get the gist.
I had a friend who recently left the IT company he was working for and after 2 months of job search we caught up, here is what he said: “It is actually quite hard to find a job if you don’t have any skills beyond excel and MS project, the market is looking for people who understand the technology you are dealing with”. You end up with two choices you get some of the younger guns for the newest set of technologies or someone much older who still has the technical skills of well established technologies, but is that sustainable?

So what should you do:
I think you need to find a way to create the next generation of technical leaders. Technology and specifically software will remain an important part of your business. It is unrealistic to expect to all IT work in-house and onshore, but to really drive technology to the extent that you need to, it is important to retain technical talent. Create some roles in your team that are onshore even if it is unpopular. The investment you make here is small and will pay back easily if you can keep good technical people around and grow them as the next technology leaders in your company.

Picture: The Fall by Celine Nadeau
License: Creative Commons

Distributed Agile – An oxymoron?

2 Replies

It is time for me to put on paper (well not really paper…but you know what I mean) my thoughts on distributed Agile. I have worked with both distributed and co-located Agile. Distributed Agile is a reality, but there are a lot of myths surrounding it. I had some queries over the last few months where people were trying to compare co-located teams with distributed teams.

networkLet’s start by talking about one of the things that is being brought up again and again: “Agile works best with a small number of clever people in a room together”. Now I agree that this will be one of the best performing teams, but I would stipulate that in that situation you don’t need a methodology at all and that the team will be performing very well still. The power of Agile is the rigor it brings to your delivery when you either don’t have very experienced people in the team or when you are  a distributed team.

Now why would you choose a distributed Agile model?

  • Scaling up. It can be very difficult to quickly find enough people in your location
  • Access to skills. It’s also difficult to find people with the right skills.
  • Follow-the-sun development. By working in different regions of the world, you can work around the clock which means you can bring functionality to market quicker.
  • You are already distributed. Well if your teams are already in different locations, you don’t really have a choice, do you?
  • You DO NOT chose distributed Agile because it is inherently cheaper or better. That is a misconception.

The goal of distributed Agile is to get as close as possible to the performance the same team would be capable of if they were co-located.

distributed AgileAll things being equal, I don’t believe a distributed team will ever outperform a co-located team. But then all things are never equal. The best distributed teams are better performing than 80% of the co-located teams (see graph on the left). So it is important in both co-located and distributed Agile to get a well working team together. Improving the performance of your team is more important than the location of the members.

There are however factors that help you achieve an experience close to co-locations.

  • Invest in everything that has to do with communication: Webcams, Instant Messengers, Video conferencing,… And really make this one count, spending 10 minutes each time to enable a connection costs a lot of productive time over a sprint.
  • Physical workspace – where team members are co-located they need to have the right physical environment and shouldn’t sit among hundreds of other people who disturb them
  • Invest in virtual tooling like wikis, discussion boards etc.
  • Find ways to get to know each other. This happens naturally for co-located teams, but requires effort for distributed teams. Spend 10 min in each sprint review introducing a team member or create virtual challenges or social events in second life or world of warcraft.
  • Don’t save a few dollars on travel. Get key stakeholders or team members to travel to the other location so that you at least for a short period of time can enjoy the richness of communication that comes with co-location.
  • Agree on virtual etiquette – what should each team member do on calls or in forums. Retrospectives and Sprint reviews require some additional thought to really hear from everyone.

If you do all that you have a team that operates nearly as if co-located. And if you really want to push the performance of your team further then I have an answer as well:

  • Look at your engineering practices
  • Look at your tools
  • Implement DevOps/ContinuousDelivery/Continuous Integration

That will really push your productivity, much more than any methodology or location choice could possibly do.

DevOps for Systems of Record – DevOps Summit Melbourne 21st of November

Leave a reply

Update – The DevOps summit has been postponed until early next year.

This time I just want to provide a quick teaser about my upcoming talk at the DevOps summit in Melbourne about DevOps for Systems of Record. I will highlight in this talk my experiences from two case studies, one with Mainframe and one with Siebel and share lessons learned.

IBM_Blue_Gene_P_supercomputerThe talk will highlight four different principles of dealing with Systems of Records in your DevOps adoption:
Principle 1 – Overcoming Culture
Principle 2 – Tenacity over Vendor Advice
Principle 3 – A word about Maturity Models
Principle 4 – DevOps changes everything

After the talk I will provide a more detailed post about the topic, but for now you will have to come over to the Melbourne Convention and Exhibition Centre to hear me speak about it. Check this link for details about the summit: http://www.devops-summit.org/Melbourne

DevOps and Outsourcing: Are we ready for this? – A view from both sides

3 Replies

At the recent DevOps Enterprise Summit #DOES14 (http://devopsenterprisesummit.com) I was surprised to hear so little about the challenges and opportunities of working with systems integrators. Reality is that most large organisations work with system integrators and their DevOps journey needs to include them. With this blog post I want to start the conversation about it and let you in on my world, because I think this is an important discussion if we want DevOps to become the new normal, the “traditional”…

connect-316638_1280Let’s start with terminology – I think you will struggle with the culture change if you call the other party system integrator, outsourcer, vendor, 3rd party. I prefer the term delivery partner. Anything other than a partnership mindset will not achieve the right culture that you need to establish on both sides. I will talk about the culture aspect later in the post, but terminology can make such a difference, consider the difference between the terms tester and quality engineer.

A bit of my personal history to provide some context – feel free to skip to the next paragraph if you are after the meat of this blog post.
I have been working for a large system integrator for many years now and have been part of DevOps journeys on both sides – as the delivery partner (notice the choice of words ;-)) and in staff augmentation roles dealing with my own company and other delivery partners as a client. To use the metaphor used at #DOES14 – I am more of a horsewhisperer than a unicorns handler. And I wouldn’t want to have it any other way. That means my DevOps journeys deal mostly with Systems of Record (think Mainframe, Siebel, etc.) and yes once in a while I get to play with the easier stacks like Java and .NET. So my perspective is really from a large enterprise context and while it is sometimes tiring to see the speed we are moving at, it is a fascinating place to be in and gives you such satisfaction when you have success. Together with passionate people on both the client side and on my team, we have saved one client over 5000 days of manual effort per year or reduced deployment times from over 2 days to less than 3 hours at another client. This is amazing to see and I cannot wait to tackle each new challenge. One item on my bucket list is to drill open SAP and “DevOps-ify” it, just need to find the right organisation that is willing to go there. But enough about myself.

Working with Delivery Partners who develop applications for you
The elephant in the room is probably setting up the right contract with your delivery partner. This is not easy – Agile coaches will tell you that Fixed Price is evil, but if you go for a T&M model your delivery partner has no incentive to reduce manual labour as he gets paid for each manual step. I have seen both types of contract work and not work, so clearly it’s not the type of contract that makes the difference. But what is it then? The relationship and alignment of incentives and priorities will be important. I will talk about culture separately, so let’s look at incentives. One of the concepts that work reasonable well is if you can create a performance based incentive (e.g. measure the efforts for “DevOps service” baseline and then create an incentive for improvement, like sharing the benefit across both organisations. The SI will be happy to increase margin and the client saves money. A true Win-Win commercial construct.)

Another important aspect is culture. Don’t forget in your DevOps journey to consider the culture of your delivery partners and of the way your own organisation treats the partners. Too often outsourcing partners are not involved in the cultural shift, are not getting the communications or being invited to culture building activities. Try to understands what drives them, connect their DevOps champions with yours, give them the opportunity to provide inputs. And last but not least celebrate together!

The third aspect to consider is technical skills. It is not necessarily true that your delivery partner has the required technical skills available. Remember that you probably for a long time incentivised your partner to find staffing models that support a very low daily rate. this doesn’t change quickly and if you want to shift this you will have to address the need for technical skills and either create a structured up-skilling program or provide technical coaching from your side. Don’t just make it their problem, make it a joint problem and address it together including any required updates to the commercial arrangements. And as is true for managing your own team: assume positive intent and work from that basis.

Of course, if you don’t think the culture of the SI is DevOps aligned (and you as one client will not be able to change that easily, trust me) then you should look for a partner who is in it with you. Going in the DevOps direction is not always easy so you rather choose the right partner for the tricky path ahead of you. This is true for your Agile adoption and certainly is true for your DevOps adoption as well.

When to work with an SI in the DevOps team
Besides working with SIs who develop and maintain applications, there is also a case to be made for getting help from an SI to implement DevOps in your organisation. This is what I do for a living and I do think we can add real value. First of all, I don’t think you can outsource the DevOps implementation completely (at least I would advise against it), but you can create really mutual beneficial partnerships. What I enjoy about being an SI (okay that sounds weird), by working for an SI (that’s better) is that I have a huge internal network of people with similar challenges and with solutions for them. If I want to find the best way to automate Siebel deployments I have many colleagues who have been there before or who are doing it right now. Having access to this network and the associated skills can be very beneficial for clients. And if you setup the partnership right, both organisations can benefit. I have helped organisations setup the team, the processes and the platform and enabled them to operate it going forward. And nowadays with offshoring we can also be a long term part of the team to help with ongoing improvements. Reality is not everyone has the in-house capability to build this capability and getting a bit of external help can go a long way. If you want to do it all in-house you can grab a couple of coaches to augment, but if you want someone with skin in the game find a really good SI partner for your team.

I will stop here although there is more to be said. In one of my next posts I will focus on the inside view of an SI. What does it take to transition towards DevOps if you are fully dependent on your client in regards to process, flow of work etc. Is there something that can be done? I will tell you about one of my projects to give you an idea and to further the understanding of the role of an SI in the DevOps world.

Update 2016:
I have seen a bit more conversation about this now, the below links are worth reading if you want to know about a few more perspectives:
– Will DevOps kill outsourcing?
– The Year of Insourcing
– DevOps – The new outsourcing

Impressions from the DevOps Enterprise Summit 2014

8 Replies

I spent the last 3 days at the DevOps Enterprise summit here in San Francisco and wanted to share my thoughts with those that couldn’t come over here. Overall it was a great conference, especially if you consider that this was the first time this conference was organised. A few glitches, but that just made it more likeable. And I am sure it will be even better next year. And I have to admit that I hope not hear about horses and unicorns for a few days…

So what did I take away from the conference? Here are a few of the themes that were pretty common through the 3 days:

  • DevOps Teams – While there were certainly exceptions (most notably from Barclays), most organisations that spoke seemed to have a dedicated shared services DevOps team to focus on the tooling, governance and support of their DevOps platform. This is certainly my preferred approach as well and it was good to see that many organisation have made positive experiences with this. But it was also good to hear positive stories from organisations that have chosen a more federated approaches and to learn how they approached it successfully.
  • DevOpsSec – While obvious in hindsight, the frequent mentioning of information security as a critical element in the DevOps journey really brought this home for me. And as some of the speakers highlighted the ability to automated the compliance to regulations and policies is so powerful, that information security can actually be your ally in the DevOps journey and not a blocker. Great change of perspective for me personally.
  • Balance of Culture and Technical Practices – Not surprisingly a lot was being said about culture change and also about technical practices for DevOps. I think this balance is important and is good for us to keep in mind in our day-to-day as we sometimes get to focussed on only one side of the equation.
  • Internal Conferences – So many companies use internal conferences to spread the word and share experiences across the organisation. This is fantastic to hear and I am glad they are able to get the support for it as it can be hard to make a quantifiable business case for those as I know from experience.
  • Servers are cattle not pets – A lot was being said about the importance of having environments that are commodity and consistent, so that you can replace servers easily and reliably. Quite a few of the tool vendors were from a server monitoring, configuration management drift detection space as well. This clearly deserves more focus going forward.
  • Tooling – A completely non scientific impression is that certain tools are much more prolific than others in the DevOps toolkit, examples are: Jenkins, Atlassian tools, Git.
  • Measuring everything – Not really a new thought, but interesting to see how many of the organisations had good data to support their story. So important to get this right and use it to drill down on bottlenecks and cost sources.
  • Scaled Agile Framework – SAFe got a lot of positive mentioning by the speakers, seems to be widely adopted at large enterprises.
  • A few smaller takeaways:
    • Impact Score of Releases – I like the idea of measuring the impact of releases by measuring the sum of (number of Defects x severity). Brilliant.
    • Inverse Taylor Manoeuvre – Such a good name for self-enabled teams
    • Inverse Conway Manoeuvre –  A great name for addressing the architectural challenges that many of us face with existing architecture
    • Release notes as blog – Such a good idea to not send notes around but rather use a blog to document all release changes
    • Sprint Plan review meeting – A meeting after the sprint plan to get all relevant stakeholder across the plan (like Ops, InfoSec, Business). Great idea to test.
  • Favourite Quotes:
    • “Branches are evil”
    • “There is a right way to develop software (and DevOps is it)”
    • “We geeks don’t just like SkyNey – we want to build it”
    • “Cease dependence on mass inspection to achieve quality”
    • “Just talking nicely to each other does not delivery software”
    • “Time does not make software better”

A few things could be improved going forward in my opinion:

  • Many of the Enterprise Scale organisations were talking about their Web presence or Digital space, and only a few talked about the DevOps transformation for their Systems of Record. A better balance would be nice, to not only hear the positive stories and learn from the really difficult cases
  • One aspect that was only mentioned as a sidenote and by 2 or 3 speakers is the reality of working with many different vendors and systems integrators. How do you enable this multi-party setup for DevOps practices? Having been on both sides of that story, perhaps I should share my experiences next year…
  • The sessions were pretty much back-to-back and there was little time for Q&A and to ask informal questions. Perhaps a short break in between sessions or a more formal way to socialise with the speaker right after the session would be good. I have seen this very successful at other conferences.

And last but not least a shout-out to some of the outstanding speakers from the conference, if you get a chance check-out the recordings later in the week when they are available on the conference website at http://devopsenterprisesummit.com.
– Gary Gruver
– Em Campbell-Pretty
– Jason Cox
– Mark Schwarz
– Owen Gardner
– Carmen DeArdo
– to highlight just a few, there were many more that are worth listening to if you have the time

Agile Reporting at the enterprise level – where to look? (Part 1 – Status reporting)

4 Replies

In this week’s post I will talk about a topic close to my heart. How do you manage Agile projects if you have some scale. And especially how do you report on progress and use the lessons from your projects effectively across the enterprise? Let’s start by looking at what we want to get out of the reporting.

What should a good report show you:

  1. How has the scope changed over time?
  2. How much scope have we successfully completed?
  3. How is the team progressing towards the goal over time?
  4. How are we doing with cost?
  5. How is this team progressing compared to other teams?
  6. Which teams should I help to get them back on track? 

So here is the first example of a “traditional” Agile release burn-up that gives us information for points 1-3:
burnupSo how do you read this report? The first line shows how the target scope developed over time. In this case you can see that the number of story points required moved a bit up and down as stories were delivered. This is pretty normal for an agile project, nothing to worry here. We have an ideal line to show us what the “ideal” amount of accepted story points would be, of course no team ever delivers according to this line. If they do, I would ask a few questions as it just looks too good to be true – perhaps we bend the truth a bit in those cases to not explain the difference…

The actual burn-up and the predictions that the team tracks let me to the conclusion that this will be close, but that they can make it. This is a team I will keep an eye on going forward to see whether they catch-up as predicted. As the overall trend of total scope is also slightly downwards, there is a chance that the trend continues to a number even below 911 story points, which would be good for this team. 

Challenges with Agile reporting (points 4 & 5) 

If you are like me and are working in an enterprise environment it is likely that your teams use different iteration schedules, don’t have an aligned story point structure and are of different size. If you look at the release burn-up graphs, you can hardly compare them and by looking at many across the enterprise you don’t necessarily are able to compare their progress. Here is where my favourite report comes in – the relative burn-up that answers point 5 from our list of requirements.

relative burnupThe beauty is that you can show all kinds of things on this graph. In the example shown here, we track the progress of accepted scope against the budget (point 4) that we have used (and yes we are falling behind, looks like we need more budget to deliver our scope). Of course you can do the same for scope vs. schedule. And because these reports are relative to 100% of scope, budget or schedule you can now compare your status reports across teams. We are all aware that status is not linear and that the ideal line is mostly to be ignored, but if after the release has finished you look back at the teams that were successful and those that had challenges you can look for patterns. What percentage of scope did successful teams delivery after 50% of their schedule? How much budget did they have left after they completed 90% of the scope? Through this insight you can develop a portfolio view that I describe later.

One of the biggest challenges: How accurate is the data

Before I do that I want to share one more challenge: Real-Time data. It is near impossible in my experience to get good reporting if you have to manually collate the data and/or the report is purely used for outside stakeholders. To make your reporting effective you should explore ways to make the report automatic based on data that your team already provides rather than making it a separate activity. And to avoid the challenge of stale data, make it part of your stand-up to look at the report; this will help keeping people motivated to update their data. Ideally in any status meetings you have you and your stakeholders look at the tool you use and not extracts, excel sheets or PowerPoint slides; but I have not seen many organisations doing this successfully. 

And now to the promised portfolio view (point 6):
How to keep track of many projects or teams in your organisation? In the manual for Agile it says that you should get your status by attending stand-ups. How do you do that if you have 20 teams working at the same time? I think we all understand that some kind of reporting will be required and as long as it is helpful and used for the right purpose (to provide help where required, not to call teams out where they struggle) we all want that kind of visibility. If you have the relative reporting in place that I mentioned above, you can now use this to get a good view of your teams and you can chart your learning from the past into the report. It could look like this (this is still conceptual as I have not yet implemented it on my program):

portfolio

If you use the relative burn-ups you can now draw each of the teams on portfolio map like the above. Depending on how far they are through their scheduled iterations and how much scope has been accepted you position them on this map. From your experience with successful and challenged teams you know which area is green, amber and red (this will differ from organisation to organisation). But now you can quickly see for which teams it is worthwhile to look at them a bit closer. In the above example the size of the team (size of bubble) and the planned release date (colour) are also shown. As enterprise coach I would talk to the team represented by the large red bubble at 50% of schedule and the small red bubble at 85% of their schedule. At this point you will have to understand the context of these teams to see whether they need help or not. This diagram makes watermelon status (appearing green from the outside but really being red) less likely as it is purely based on the agile burn-up information and your experiences in the organisation. I will let you know how well this works once I have implemented it successfully.

Now this is one aspect of reporting done (status), I will talk about how to report on delivery health in the next post, where we will talk about a delivery health score card and cumulative flow diagrams. As always reach out if you have thoughts or perhaps even good examples.