Author Archives: Mirco Hering

Working with SIs in a DevOps/Agile delivery model

1 Reply

In this blog post (another of my DevOps SI series), I want to explore the contractual aspects of working with SI (System Integrator). At the highest level there are three models that I have come across:

  • Fixed Price contract – Unfortunately these are not very flexible and usually require a level of detail to define the outcome, which is counterproductive for Agile engagements. It does however incentivise the SI to use best practices to reduce the cost of delivery.
  • Time and Material – This is the most flexible model that easily accommodates any scope changes. The challenge for this one is that the SI does not have an incentive to increase the level of automation because each manual step adds to the revenue the SI makes.
  • Gain Share – This is a great model if your SI is willing to share the gains and risks of your business model. While this is the ideal model, often it is not easy to agree on the contribution that the specific application makes to the overall business.

So what is my preferred model? Well let me start by saying that the contract itself will only ever be one aspect to consider, the overall partnership culture will likely make a bigger impact than the contract itself. I have worked with many different models and have made them work even when they were a hindrance for the Agile delivery approach. However, if I had to define a model that I consider most suitable (Ceteris Paribus – all other things being equal), I would agree on a time and materials contract to keep the flexibility. I would make it mandatory to do joint planning sessions so that both staff movements and release schedule are done in true partnership (it does not help if the SI has staffing issues the client is not aware of or the client makes any ramp-ups/ramp-downs the SI’s problem). I would agree on two scorecards that I would use to evaluate the partnership. One is a Delivery Scorecard, which shows the performance of delivery, things like: are we on track, have we delivered to our promises, is our delivery predictable. The second is an Operational Scorecard , which shows: the quality of delivery, the automation levels in place, the cycle times for key processes in the SDLC.

With these elements I feel that you can have a very fruitful partnership that truly brings together the best of both worlds.

How to support Multi-Speed IT with DevOps and Agile

5 Replies

These days a lot of organisations talk about Multi-Speed IT, so I thought I’d share my thoughts on this. I think the concept has been around for a while but now there is a nice label to associate this idea. Let’s start by looking at why Multi-Speed IT is important. The idea is best illustrated by a picture of two interlocking gears of different sizes and by using a simple example to explain the concept.

The smaller gear moves much faster than the larger one, but where the two gears interlock they gearsremain aligned to not stop the motion. But what does this mean in reality? Think about a banking app on your mobile. Your bank might update the app on a weekly basis with new functionality like reporting and/or improved user interface. That is a reasonable fast release cycle. The mainframe system that sits in the background and provides the mobile app with your account balance and transaction details does not have to change at the same speed. In fact it might only have to provide a new service for the mobile app once every quarter. Nonetheless the changes between those two systems need to align when new functionality is rolled out. However, it doesn’t mean both systems need to release at the same speed. In general, the customer facing systems are the fast applications (Systems of Engagement, Digital) and the slower ones are the Systems of Record or backend systems. The release cycles should take this into consideration.

So how do you get ready for the Multi-Speed IT Delivery Model?

  • Release Strategy (Agile) – Identify functionality that requires changes in multiple systems and ones that can be done in isolation. If you follow an Agile approach, you can align every n-th release for releasing functionality that is aligned while the releases in between can deliver isolated changes for the fast moving applications.
  • Application Architecture – Use versioned interface agreements so that you can decouple the gears (read applications) temporarily. This means you can release a new version of a backend system or a front-end system without impacting current functionality of the other. Once the other system catches up, new functionality becomes available across the system. This allows you to keep to your individual release schedule, which in turn means delivery is a lot less complex and interdependent. In the picture I used above, think of this as the clutch that temporarily disengages the gears.
  • Technical Practices and Tools (DevOps) – If the application architecture decoupling is the clutch, then the technical practices and tools are the grease. This is where DevOps comes into the picture. The whole idea of the Multi-Speed IT is to make the delivery of functionality less interdependent. On the flip side, you need to spend more effort on getting the right practices and tools in place to support this. For example you want to make sure that you can quickly test the different interface versions with automated testing, you need to have good version control to make sure you have in place the right components for each application, you also want to make sure you can manage your codeline very well through abstractions and branching where required. And the basics of configuration management, packaging and deployment will become even more important as you want to reduce the number of variables you have to deal with in your environments. You better remove those variables introduced through manual steps by having these processes completely automated.
  • Testing strategies – Given that you are now dealing with multiple versions of components being in the environment at the same time, you have to rethink your testing strategies. The rules of combinatorics make it very clear that it only takes a few different variables before it becomes unmanageable to test all permutations. So we need to think about different testing strategies that focus on valid permutations and risk profiles. After all, functionality that is not yet live requires less testing than the ones that will go live next.

The above points cover the technical aspects but to get there you will also have to solve some of the organisational challenges. Let me just highlight 3 of them here:

  • Partnership with delivery partners – It will be important to choose your partners wisely. Perhaps it helps to think of your partner ecosystem in three categories: Innovators (the ones who work with you in innovative spaces and with new technologies), Workhorses (the ones who support your core business applications that continue to change) and Commodities (the ones who run legacy applications that don’t require much new functionality and attention). It should be clear that you need to treat them differently in regards to contracts and incentives. I will blog later about the best way to incentivise your workhorses, the area that I see most challenges in.
  • Application Portfolio Management – Of course to find the right partner you first need to understand what your needs are. Look across your application portfolio and determine where your applications sit across the following dimensions: Importance to business, exposure to customers, frequency of change, and volume of change. Based on this you can find the right partner to optimise the outcome for each application.
  • Governance – Last but not least governance in very important. In a multi-speed IT world you will need flexible governance. One size fits all will not be good enough. You will need light-weight system driven governance for your high-speed applications and you can probably afford a more powerpoint/excel driven manual governance for your slower changing applications. If you can run status reports of live systems (like Jira, RTC or TFS) for your fast applications you are another step closer to mastering the multi-speed IT world.

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

1 Reply

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