Tom Peruzzi's thoughts on digital, innovation, IT and operations

Becoming agile in an “I think I’m agile” environment…

Posted in development, startup failures by opstakes on March 21, 2016

Imagine you start a new leading job in a company which calls itself agile. Later on you recognize that even if they somehow do some agile stuff they are far away from agility. The mindset is generally right, skill level high but collaboration with business broken, push and pull in parallel, tools over collaboration and way more.
So where and how do you start? Literature is much more focused on how to start becoming agile than turning around such an organisation. Mindset, know-how, skills and attitude are ok but to be challenged …
Now, a few sprints later we can share some of the insights we gained during our journey and yes, we were successful 🙂

  1. Start with a spontaneous break! From one day to the other we simply informed everyone that from tomorrow on we will work the following: review and retro every second Friday, planing 1 and 2 every second Monday, daily grooming and bi-weekly sprints. Knowing that we pushed hard, it was the ultimate challenge to switch from one day to the other. There was simply no time for long discussions, collaboration was down, lots of complaints from the business and the simple need to get back to delivery mode. I know that some of the devs hated us for doing so, radically introducing transparency isn’t easy but if you have just one silver bullet please consider it carefully and this was our silver bullet.
  2. Stay near the teams, moderate and coach but don’t take over
    For the next couple of weeks we did our very best to stay near the teams, helped them in getting up with the process, getting their buy-in. We helped them with one-on-one and team sessions, but it was up to them to buy-in and adapt it according to their exact need. Everything was ok as long as it didn’t conflict with our main goals: transparency and predictability.
  3. Physical boards
    We love confluence and jira, yes we do. Even so we decided to track on epic and story level in Jira but do our daily work on physical boards. The reason is simple: The only thing our business is interested in is getting stories done, no matter how we achieve it. And we wanted to avoid business asking questions on simple task level or starting getting nervous if a task isn’t done in time. So simply for resilience and overview we organized that media break. We started with task planing on the board. After a while we adjusted slightly like:

    • when a task isn’t done in one day (we broke it down like that) we put a red dot on it so it becomes visible to all of us
    • we learned to break it down in single-day tasks. Even if that produces a lot more paperwork it is crucial for success to get doable and trackable pieces of work.
  4. Get out of the daily routines
    Once you recognize things moving in the right direction get out of daily routines. If you see grooming going the right direction, let them groom without you, same for retro and review. Just step in occasionally to quick check direction. Trust your teams – if you don’t trust, switch back to waterfall. No agile approach without a certain amount of trust…
  5. Wait with KPIs
    There would have been tons of interesting KPIs but first they hinder you from learning and from reaching a certain flow-level. Start estimating from day one but don’t take care on burn down for the first 3 sprints. As long as the team is still experimenting with estimations it isn’t worth too much. Look at stories completed only and check (5 why) why some stories didn’t happen even if we committed to deliver. Look for qualitative signals indicating you right direction or not. After 4-5 sprints start with simple, easy to maintain KPIs. Otherwise you will not be able to fine tune later.
  6. Get stakeholder’s support and willingness to change!
    Looking at our org-chart: our POs are not part of our tech organisation, they are within their product-focused teams. Imagine you implement a process which affects all teams (as they all rely on you)… We do spend a lot of time on grooming, lots of hours day per day. Everyone is allowed to join, so even if grooming takes just 30 min (timeboxed) getting 10 people in results in 35 hours a week on grooming. Is it worth the effort? Yes it is, stories get better and better, devs understand business way better than a few months ago and business starts understanding us, our needs and constraints. Agile development is agile product development, it’s not a tech process only. Without the understanding of the problem and the acceptance of your stakeholders you are not able to change anything. So get their buy-in and make sure that they adopt as fast as you change. Inform them pro-actively, there is not enough communication, just too little.
  7. reward success, celebrate failure, punish inaction
    Robert Sutton once said that and he is 100% true. So how do you change without making failures? That’s simply not possible so think about how to make failures a success. Whenever you somehow fail, don’t blame others. Think about why you failed and how you can avoid that in the future. Spread that knowhow and then celebrate the successful learning. But don’t forget to reward successful actions too, go out for team dinner, acknowledge new learnings and small successes too, let people know you see and appreciate the progress. And really punish inaction. If you want to strive for success you need people who are willing and eager to go the extra mile, complete the work, adapt to changes. If one does no longer fit into that team and its framing conditions, than it’s not the team. Give responsibility to the team, if it is a good one it will filter out inactive or inappropriately behaving persons. If you see one being inactive and the team isn’t, than challenge the team, maybe they still have to learn a lot.
  8. avoid mediocrity
    If you push hard for transparency and predictability your team may be willing to undercommit in order to deliver properly. Without hitting the limits you will not become better. Push your teams hard but create achievable sprint goals. Don’t burn them but do your very best to avoid mediocrity. I would rather go for a slight over-commitment than an undercommitment. If the team is really willing to drive, they will potentially spend more time on delivering what they promised. Don’t forget, trust is the clue of agility. Devs trust POs to understand customer needs, POs trust devs to deliver what they promised. So keep a good balance, have an eye on your team’s performance and your team’s mood and either push hard once or give them some time to recover. No team can over-deliver 52 weeks a year!
  9. Challenge their agile mindset
    Challenge it daily, weekly, monthly. If they think they are agile they should at any time be able to answer why they act as they do now. Ask the 5 Whys and dig deep. Pray the agile mindset and live the agile mindset. Don’t expect them to act if you are not willing to change too. Group them properly, allow pair programming, foster collaboration and communication. Pin the agile manifest on each free wall, bring in real agile thinkers and let them discuss, celebrate agility, train agile routines and always remind them of the benefit. Let them explain agility to others (e.g applicants for an open developer job). Don’t persuade them, if one opts out it is his/her decision but they should understand any consequence too. Don’t push them to hard. If they don’t move ask them about their motivation to stay as is, show them paths to go forward, help them develop and change their mindset. Put more optimistic people in each team and only ask for a certain level of patience before they opt out. Anyone should be OK to try at least 3 sprints before he/she decides to opt out.
  10. Get a neutral moderator in
    Have one in the organisation who is not in an operational role. Call him moderator, mentor, coach, whatever but not any known scrum-name. That person is a super critical resource. His/her job is to get the buy-in from all parties in long-lasting one-on-one sessions, cleaning up the boards, doing sanity work, pushing for excellence. Don’t call it a scrum master, the role is much more. It is a neutral driver for success on a temporary basis. The one and only job is to get the push done, get the buy-in of the people and take care to not become an essential party in the story. This may be an ideal role for an external as long as the external doesn’t act like an external consultant, it must be a much deeper, personal, yet professional link between him/her and the organisation.

There is a lot more one could consider. To sum up one more essential for me: If people think they are agile, challenge them with agility, don’t adapt your new process to fast, let them tryout and learn before, keep the agile mindset and values in focus, go down the path with your team.

 

Advertisements

the scrum story – I’m back

Posted in development by opstakes on December 6, 2012

dear all

It’s quite along ago writing my last article but now I’m back. The reason why? I had so much to do and I really struggled whether to continue or not. I will change slightly and bring in more stories related to IT in general not only IT ops any longer.

I currently do work a lot with scrum and with the all time discussion which and how and scrum, scrumban, kanban or whatever rules. For me the most important is the aspect D. Pink brought up in his wonderful book Drive (I would strongly recommend reading it before implementing any sort of agility!)

What he tells us is that the main 3 drivers for motivation and drive are autonomy, mastery and purpose where autonomy is meant in time, task, team and technology. Scrum takes care on that on a certain level but not that explicit and even so the more enterprise scrum you have and the more silo oriented (aka component driven) the harder it is to establish that sort of autonomy. There are plenty of good examples out there how really big hip organisations organized their scrum-teams. What we did as a way in between traditional oriented teams (the more enterprise ones thinking in know-how silos) and hippy cool stuff was the introduction of some infrastructure driven (silo oriented) teams providing APIs where the feature-driven teams can rely on. The trick is, and future will show whether we are true or not, that the API teams must run 2 sprints ahead and have a pretty good unterstanding of what is needed on API level in future.

Why did we do so? Well if you have component driven teams from the past which started already to work, a lot of missing competence in new core parts of a new platform and only the chance to fill that gap with external companies (not contractors) being able to provide that sort of knowledge as part of shared license and times&material .. well, then you have to act the way we did or you thing in raw silos only and try to manage the dependencies between those story per story.

I assume that there are pretty more ideas out there but velocity, engagement and teaming-level shows us that we are on a pretty good road right now. If you have any other or better experience feel free to share, would be happy to get more info!

Tom

Tagged with: ,

cloud reloaded

Posted in financial, startup failures, technical by opstakes on October 7, 2010

I had the chance to present some general thoughts on cloud computing on an aicooma and Microsoft event yesterday.
While being in general a pro cloud geek especially for operations I got some more hints to cover:

  • scrum & cloud really cooperate well on a very high level (aicooma will present some whitepaper regarding that topic soon)
  • the deeper you look at all potential hidden costs the less interesting a cloud offer looks like in the first, but keep in mind that you always have to take care on a service lifecycle perspective
  • Moving from Managed Services to a real cloud offering is quite hard, on the one hand side for the moving organization to get an understanding and feeling for the cloud, on the other hand side for the partner, right now nearly all major outsourcing parties claim to offer cloud but the contract looks quite different afterwards …
  • Even cloud vendors now tell the truth: a cloud will never ever fit into each setup

Dealing with that topics it shows that there is still some FUD in regarding how cloud computing could help me, my department my organization and whether it fits or not. A quite good way would be like I do in general:

  1. Get your service catalogue and your service portfolio up
  2. Include lifecycle infos into portfolio (time of reinvest …)
  3. take the 5 out where reinvest should occur within next 18 months
  4. have a very deep look (organizational, technical, financial) on those 5
  5. find a potential cloud substitute
  6. compare in depth

After doing this once or twice it’s getting quite easy to deal with, it is not that much work as it looks like in the beginning but it offers you a very transparent view on your portfolio and on the potential of cloud offerings being out and stable right now, more or less it demystifies cloud offerings and makes them compareable to your internal or external managed services like comparing apples with apples, and that’s the goal, nothing about emotions, coolness or hype, realistic and transparent decision taking is king.

Tagged with: , ,

The Agility stuff

Posted in general failures, startup failures by opstakes on September 23, 2010

Whenever we hear terms like agility, scrum, XP, KanBan or whatever most people think like “This is cool development and innovation stuff, ops doesn’t have to care on that” NOT TRUE!!!

Whenever you hear something about a new development methodology, framework or anything else be prepared, changing developments life will change your interfaces hence your operational life too!

And better to act on interfaces than reacting. We currently do a lot of investigation on cloud, agile and how it changes our ops life but to be honest, agility drives the operational need for clouds.

Think about the following: You best act with scrum teams if you show them your boarders and limitations (aka frameworks, standards, tec. recommendations) and act as an active stakeholder with and within the scrum team. The better the teams will be, the more they will need agile resources from your ops department. Flexibility or agility can be achieved by a bunch of technologies and with different investment scenarios but one which probably fits best is reacting with cloud computing resources or highly available virtual resources (hence highly automated and “near cloud”) and provide proper feedback to the agile teams.
Doing so you will get a very high throughput within your IT organization, tons of congratulations as you were one of the very rare operators thinking in business terms and needs and you will get a very effective and efficient ops team with strict and accepted boarders. The better and clearer they are, the better your automatisation is, the better agility is supported and the better feedback will be.
If not, do what you have to do with such developers 😉
I will keep on writing about agility and cloud operations as I personally believe this is the way we will operate the next years long.

Tagged with: , ,
%d bloggers like this: