Two weeks ago I spent three days in sunny, yet chilly Las Vegas at CA World (yes Vegas was suffering from a cold spell). CA World is the premier event for CA customers, a chance to hear what is new with CA technologies, share customer experiences and connect with product management and CA leadership on the future of CA products and offerings.
Tasktop had a booth in the ca Intellicenter. This zone included many tools including CA PPM–The market leading PPM tool. We have a long relationship with CA, delivering OEM versions of Tasktop Sync and Tasktop Dev in support of their Agile planning and requirements tools. But what is interesting today is how customers are using Tasktop Sync to connect to other tools in the stack, and how organizations are marrying traditional PMO practices associated with allocation, planning and financial measurement to development teams following Agile development practices. Many of you have heard me talk about water-scrum-fall, and how as Agile crosses the chasm to be mainstream the reality of modern development is a hybrid of traditional approaches and Agile development. The first part of the phrase ‘water-scrum’ references the marriage between traditional planning and reporting lifecycles with Agile or Scrum based processes. During CA World I talked to many large companies who are wrestling with that need and here are some of the observations I took away from the event:
Agile and the PMO can work together in ‘almost’ perfect harmony.
There are some in the Agile community who state that the only way to create an Agile enterprise is to discard all traditional planning models and embrace an approach that marries Agile teams to the business, allowing them to directly deliver business value in response to business need. Planning is done at the business level, allocating development resources by business priority. The role of the PMO is removed, because the business plans the work, thus negating the need for a middle-man. But the reality is that ‘the business’ is much more complex than one group, and the supporting applications are a spider’s web of interconnected, disparate systems.
There is the need to manage the spider’s web – allowing Agile teams to serve one set of objectives whilst managing the large number of cross team dependencies. The PMO and the practices they provide enable teams to bridge the gap between Agile teams– focused on clear business problems-and complex portfolio release problems. But it does require some level of structure and discipline.
Time to discard old ways of connecting the PMO and move to a disciplined approach
Ironic that for many organizations the adoption of Agile at Scale requires them to introduce more, rather than less discipline. Existing ‘traditional’ processes provided only a limited amount of structure. They encouraged certain meetings and artifacts, but because they did not mirror the reality of modern software development and did not support the level of chaos created by software development, often they required very skilled project managers or PMO staff to marry the processes together with manual, email heavy, spreadsheet centric practices. This knitting process happened at least twice—once, in the translation of the portfolio plan to development activities and second, when status reporting is required. These heroes buzz around the collection of teams, setting them in the right direction and then helping them report status in a way that makes sense to the original plan. But with Agile, that process is bound to fail. Not only do Agile teams need to have a clear direction at the start, but work is grouped into much smaller batch sizes, encouraging more frequent feedback into the portfolio.
That means that the PMO heroes will become a friction point in the process and will either greatly reduce the effectiveness of the development teams, or have to increase their workload. The reality is these roles burn out, or the Agile teams get so frustrated that they ignore the PMO providing limited information. This lack of information results in lack of planning of foresight leading to last minute decisions and lots of emergencies. Instead, smart organizations are actually stepping up their game and putting in place an automated, disciplined process that enables Agile teams and the PMO to work together. It requires definition of what various artifacts mean and how those artifacts map together. For example, does development actually have a one to one mapping of projects to the PMO projects, or is a project just a backlog fed by many projects? By making real, implementable decisions about how the lifecycles connect and then automating them, teams not only allow for frequent reporting, but also ensure that work flows from planning to development. It also enables, often for the first time, the ability to change a plan based on real feedback and data.
Resource Management is different, but manageable.
Yes, Agile teams do not like to think in terms of people, instead focusing on team capability (known as velocity). But at the end of the day people cost money and need to be accounted for. One of the key debates at CA World was the role of the resource and how timesheets fit into the model. And, the answer is ‘it depends, but you have to pick one model and follow it consistently.’ For some organizations work comes in, is planned, by the PMO, allocated to people and those people happen to be in teams working in an Agile way.
Thus, tasks in CA PPM relate to stories in the development tool and work is defined by the story, time is tracked in that context. But it’s different for other organizations. Work is not really planned in detail within the PMO. Instead, it is allocated to a team based on some sizing metric. That work is then planned in the development/Agile tool of choice, stories are broken down into tasks and those tasks are estimated and worked on by the development teams. All of that information is then passed back to the PMO, allowing a reconciliation of the original plan to the work being done. Of course there are many variations on these two planning themes, but that is ok, as long as the organization, or at least the team, does it consistently. Also, the different levels of planning can be taken advantage of, allowing an iterative, cross lifecycle planning model.
So what is the bottom line…
CA World reminded me that Agile has grown up. There were many meetings, and discussions at our booth where people who traditionally would have been anti-Agile were discussing not only the problems of Agile development, but how they can make it work within the constraints of their existing planning, reporting and accounting processes. Over the next few months we at Tasktop are going to be working on sharing some of the models we are seeing around scaling Agile, and connecting the water-scrum part of the lifecycle. CA World not only got me excited again about the role of the PMO in Agile, but also introduced me to many organizations that are working out great solutions… Exciting times ahead, so watch this space.
