Thursday 3 May 2018

The Phoenix Project - some thoughts



Recently we ran a number of Phoenix Project simulations for an organisation who are in the process of developing product teams, which the CIO noted “...will be self-contained, self-managed and empowered to deliver services associated with critical business value streams”. Part of this transformation involved the IT department’s lead team experiencing The Phoenix Project simulation for themselves and then, having agreed on the benefit, running a further two, so far, for two of the new product teams.

Both groups who took part in the simulations included technical roles (Developers, Testers, Support, Monitoring, etc.) and representatives from the business teams for each product, including CIO and Directors. One of the teams was new; so new, that the day of the simulation was their very first day working together.

I’m not going to provide any spoilers about how the days went, other than to share some findings.

With a mix of IT and Business representatives taking part, we made sure that IT team members took the roles of Parts Unlimited business representatives (CFO, HR & Retail Operations) and those from the wider business, took IT roles. Within the IT representatives, we made sure that nobody had a role similar to their day job. That mix created some good talking points from the very start.

As round one was started some people dropped into their day job role and took control of certain aspects of the round. For one team, this worked really well and round one was a roaring success. For another group, less so. However, following the reflection and some advice provided on how improvements could be made, the team who didn’t do so well in round 1, listened and used their preparation time to improve their approach. The other team, who did well, didn’t prepare as much and struggled in the second round.

As the day progressed, it became apparent that those IT representatives in Business roles in the simulation were learning much about the value of planning, and they were sharing what they learned. All, eventually, understood the value of preparing along with a few other key things which I won’t share here. The Business representatives in IT roles for the day were able to see what was required from them in their usual roles and identified improvements they could make.

The days went well with both groups having many takeaways which would help them establish their new teams and drive collaboration and improvements based on the principles of DevOps. The team who were together for the first time, started as a room of individuals and left as a team, made up of IT and Business people. Both groups left as more cohesive and collaborative teams than when they started.

So what can you get from participating in The Phoenix Project?

  • Your teams can learn how to use the DevOps principles and ideas to improve their way of working, whether they are currently involved in development or not. 
  • Teams can bond over shared challenges, whether they are established teams, or brand new teams. 
  • You don’t need to be involved in IT to get value from the day, or DevOps. DevOps, after all is enterprise wide, so anybody involved in the development or support of business value can benefit from this simulation. 
  • Senior leaders in organisations can get hands-on high level experience of Lean, DevOps, Agile and Service Management principles. 
  • Teams starting out on the DevOps journey can experience the essence of what it means and take away ideas to use the next day. 

If you are interested in running The Phoenix Project simulation at your organisation, get in touch.

Thursday 22 March 2018

Teamwork - a thought

A while ago I responded to a statement that millennials and Gen Y people expect to be able to use any device of their choosing at work. My response (and I can't remember where I had this hissy-fit) was along the lines of "Tough! Once we grow up, we have to toe the line, and sometimes that means using and doing stuff that seems daft". However, going through the VeriSM BoK and there is a statement
that goes
"the nature of teams is evolving, moving away from the traditional hierarchical structure, to empowered and collaborative work units. The workers of today and especially tomorrow (Gen Y & Gen Z) have been raised in the teamwork culture and organisations need to be prepared to offer that same work environment." (emphasis mine)

Now, as a dad, I know everything, right? Nope. My initial reaction to the above statement was along the lines of "Pish!", or to be less English and more Kiwi "Yeah, Nah!" but then I got thinking. When I was at school, we sat at individual desks, in columns and learnt. Science classes were the only ones where we sat and worked in small groups. My daughters at Intermediate School and College (high school) only seem to work in groups. It's what they know. Could they join the workforce and be expected to work individually? Yes. Would they excel in that format? Probably not.

So we do need to change the way that work environments are created, not just because they are "self-entitled" Gen Y people, but because we have created that environment in schooling.

Does you work environment allow for a culture of team working (not just "in a team" but actually part of a team)? Or do you expect people to be doing their own job while working in the Finance team, or the HR team, or the Asset Management team? And I'm not saying open plan offices are the answer.

When consulting with clients about DevOps, I reinforce the culture, collaboration & teams aspect, which of course if you are considering becoming part of the DevOps movement in your organisation, means changing the culture across the whole organisation, but this needs to work across all teams in all organisations whether DevOps is something being considered or not. I also always like to create self managing teams when helping organisations to identify and drive improvements of any kind, but this has just been a lightbulb.

Maybe I am late to the realisation party, but that one sentence has made me take stock of everything I have ignored about the way most organisations work. I don't have all the answers, but I'm thinking about it.