Devesh Kumar from Thomson Reuters asks:
I am being asked to setup agile in totality. I know to setup agile development teams. What I don’t know is how to handle Agile budgeting, How to migrate VPs to agile in higher management, what must change in HR to support agile, and what other organizational policies must change. Can you help?
You raise some complicated issues, and different people will have different experiences that can help. I bet you have been inundated with private emails, offering consulting help. I’ll just spew this stuff publicly.
You raise some issues that resonate with work that Pat Reed and I have done, specifically, and I don’t know anyone else who has done this, so:
Pat and I each independently set up capitalization and depreciation structures that work well with agile practice (she at Gap, me at Citrix Online). We both have deeply analyzed FASB and GAAP regulations (though these are US regulations, they are largely the same worldwide) and found different ways to track labor, none of which require tracking hours. If you read some superficial blog posts on this topic, you will see some retrograde advice that asserts you need to track programmer hours, but this is false and dangerous to your agile practices.
The approach I created was adopted by Citrix Online, but not until it was thoroughly vetted by CFO and Ernst and Young auditors. We were able to achieve greater verifiability than previously with waterfall. It took about a year to get it right, but afterward the bottom-line gained huge tax savings, which allowed Citrix Online to hire a lot more engineers. There was near-shock at a board meeting, when folks had to figure out what to do with an extra $10 million dollars in profit. Peripherally related to this: I have a paper appearing in Hawaii International Conference on System Science 2013 that describes how finance departments have lots of great information that can help company executives assess the overall agility of the firm, “Release Duration and Enterprise Agility.” I can send a pre-publication draft for individual requests.
How to migrate Vice Presidents?
This is a complicated issue, and as with all VP-related things, you can rarely apply a constraint or policy to VP behavior without customization and lots of hand-holding. There are two approaches that can be used simultaneously to help:
First, you can create an “agile portfolio management” system like Enterprise Scrum (see the paper referenced in this blog post: Enterprise Scrum: Scaling Scrum to the Executive Level). Enterprise Scrum extends agile thinking to larger organizations and how they invest in projects. There are some nuances here with how you start and stop projects, and how you monitor the health of projects, captured in a draft paper I could share.
Second, you can get Director and Manager teams organized into Scrum teams performing strategic activities together, with the VPs becoming their product owners. If you think herding programmers is like herding cats, you’ve not seen anything until you’ve tried to organize managers; you will need a strong ScrumMaster. However, you will find that getting managers working and organized as teams will help them better understand the principles of Scrum/Agile, and will also make them more effective collaborators.
Another great advantage of manager Scrum teams is that managers will then better understand the difference between their strategic contributions (important, even in an agile setting), which would be handled in the manager Scrum team, and their tactical contributions (largely taken over by developer team ScrumMasters, Product Owners and Teams). Middle managers left on their own often get vertigo: Many haven’t been trained to think and act strategically, and so when the tactical work they do is handled by others they can feel unwanted and unhelpful. Sometimes this results in the reversal of agile progress. Unfortunately, a lot of agile coaches take the “screw em” attitude, but do so at the peril of long-term agility. Part of your conscious transformation should be to help middle-level managers contribute strategically.
Agile HR management
Transforming HR is a huge issue long-term, though you can sometimes postpone addressing HR issues. In my role as head of Agile at Citrix Online, I rewrote job descriptions for project managers, user experience designers and engineers (and I think Pat also did at Gap) to correspond with our agile practices. This can help the company long-term. You will likely also have to change how team members are assessed and rewarded. Agile focuses on team work, and if you have individual performance rewards in your company (like most companies), at a minimum you need to reward people for contributing to raising the skills of others, rather than for exhibiting individual prowess.
There are other ways to change HR, such as rewarding and recognizing whole teams for their contributions. What should go away is highlighting individuals as “most valuable player” and stuff like that. We are all in it together, in agile, and your HR program should embrace that, otherwise you risk losing agility in the company.
Finally, you have to hire well in agile, not just engineers, product owners and ScrumMasters, but also managers. There are tons of managers, directors and VPs that will tell you they have presided over agile teams, but if their philosophy isn’t agile, it can doom an organization. Key here are attitudes: Do they talk comfortably about their own (real) failures and what they learned? If they cannot do this, they likely don’t value Kaizen, the practice of continuous improvement at the heart of agility. Do they believe in experimentation, both with production (i.e. in a Scrum team) and with product management (i.e. “lean startup” or “lean product management” methods)? Lots of interesting interview questions can be constructed around this to get to what you want to know: Will they support agile transformation with deeds, not just words?
Agile organizational policy
Like handling VPs, organizational policy is another area that depends on the personalities and constraints of your business, so “one size doesn’t fit all”. However, management structures often dictate the software architecture (see Conway’s law, https://en.wikipedia.org/wiki/
The greatest relationship with agile software production is the difference between “Feature Teams” (which are much more agile structures) and “Component Teams”. Many large software departments are organized in a “Component Team” management structure (it is almost unavoidable in a large company), and so applications are assembled from a set of components often designed in isolation by different teams. Dependency relationships between teams become a limiting factor on enterprise agility.
Many large organizations have development teams in different countries or time-zones, Cross-time-zone dependencies can easily kill your agility unless you acknowledge them and address them head-on. The vast majority of agilists will tell you that co-located teams are essential for agility. But some outlier agilists (I am cautiously in this camp) will tell you that non-co-located teams can be as effective or more effective, but international engineering groups put communication at the very top of their priority list.
How do you get it done?
Finally, on the matter of who to involve when you undertake a large-company transformation, I would suggest that you find folks that have done it successfully before. There are many in the agile community who understand how teams successfully adopt agile, and for many of them “Just self-organize!” is their clarion call. What they often forget is that the Scrum framework, particularly, has a set of constraints and roles to limit behavior so it can achieve self-organization and
All of this big-company stuff requires a lot of diplomacy to succeed.
Consultants can help you do it faster than if you do it yourself, but they also cost a lot. Consultants are often willing to tell you challenging stuff (just make sure they don’t challenge you to do stuff at a scale they’ve never done themselves, it’s a whole different ball game at corporate scale). Ideally consultants help raise the level of internal understanding rapidly. If you want them to “hire themselves out of a job”, you want them to hire at least Director level but perhaps even VP level (again, requiring a perspective that will find someone good). If you have an existing VP or CEO who should take on this transformation role, that person should have the time and commitment to take on the responsibility.
I know of a handful of consulting groups that have done this level of transformation. It’s typically a deep engagement. Look for organizations that have former engineering executives or former technical VCs. If they’ve not done an “organizational transformation” themselves, tread more carefully.
And, of course, you can DIY (do it yourself). If you do this, put together a team of people to focus on it full-time, do LOTS of research and expect to have to experiment a lot. It will be very rewarding, but more time-consuming. Also a little dangerous, It’s one thing to cheese-off a key developer, quite another to cheese-off a VP. But it is easy to inadvertently cheese someone off in an agile transformation. In my previous successful engagements, both as a full-time employee and external consultant, I had a high-level “protector” at the VP or CEO level who worked with me on diplomacy and implementation. Get this relationship established if you don’t already have it.