Try not to be yet another project management overhead

Context

Most of our teams in Thoughtworks India work for clients outside India, which results in an “All Thoughtworks team” which is quite high in the Agile maturity scale.

When I used to interview Project Managers in Thoughtworks India, I often struggled to find people who would sound reasonable to call in for an interview after a preliminary conversation.

Something I often end up asking is “Can you tell me about a difficult or puzzling issue you had to handle on the last project  or so ? “ and the answer to this would typically be

“I had to manage dependencies across multiple vendors which was really painful”

“I had people with performance issues on my team, and we could never deliver”

“Vendors did not deliver on time”

“Scope kept changing”

“Ran out of budget”

“No one was convinced about Agile in my organization”

While these were legitimate problems, no one would actually come up and say

“There were too many defects every iteration and I had a tough time figuring out the root cause”

“Our velocity was low and we did not know how to handle a particular new technology”

“We did not know how to write automated tests around a few legacy systems”

“Our build times were quite high and we had no good solution “

“We had to coach a really difficult product owner”

This made me conclude that even though it has been so many years since Agile, XP, Scrum have been around, project managers still try and manage the golden triangle of Scope, Time and Budget. And when you are a bit more senior in the organization, you are given the responsibility of managing vendors, and be christened as a program manager. There were a few people who had at least good people management skills which was a sign of hope.

What should you know as a Project Manager to be useful ?

The reality is that in a highly collaborative and self organized environment like an agile team, a project manager is considered an overhead. And a project manager who does not take interest in the product the team is building , the way the team is collaborating and some of the technical challenges on the ground, is downright useless for a team.

Solving some of the project issues in an Agile team needs a deeper understanding of the engineering practices that are used to build the product as well as an understanding of the domain and the business in which the product fits in.

If you need to be an effective project manager, you should at least have a good handle of a few things in your project such as

* What is a good User Story in your project  or are we slicing stories correctly ?

* How good is the Continuous Integration on your project and how can it be improved ?

* What is your functional automation strategy and how can you achieve the maximum benefit from it ?

* How much technical debt are you carrying on the project and what is the impact ?

* What are the difficult areas in the codebase to test, and how can you increase coverage in those areas ?

* What does the production deployment infrastructure look like and how you best utilize that information within the project to create more similar environments ?

* If you are in a stand-up meeting where a QA calls out a defect, you should be in a position to question why no test actually caught that defect before hand in the continuous integration ?

For the typical project manager who worry only about the golden triangle of Scope, Time and Cost at a high level this might seem weird. Some of them might even want to delegate it other people in the team.

In a matured agile team, the case for a project manager can be made only when he/she has a handle on some of the things mentioned above. Estimating using points, putting it in a release plan based on velocity can be done by anyone in the team.

The crux lies in understanding the product the team is building , the tools and techniques they employ to do it and the collaboration required to yield the best results !

Experience design and continuous delivery

While integrating experience design in the overall agile lifecycle is a challenge, teams working in a continuous delivery mode can prove to be a boon for experience designers.

Using the release cadence

When you are working on a longer release cadence, life of an experience designer often looks like this



















A lot of discovery and research is done upfront in the first few iterations, with usability testing happening towards the end of the release with very minimal tie left for factoring in any feedback coming from usabiity testing.

However teams practicing delivering continous releases to production often end up with a better release cadence which allows a lot of opportunities for UXers on the team to perform research, concept testing and usability testing around these shorter releases.

















This allows teams to plan fixing feedback from previous releases into future releases resulting in building a better product iteratively. These windows of opportunity should be capitalized by experience designers on the team to do regular usability testing or even corridor testing whenever possible. Even if the minor releases do not actually go live, a lot of feedback can be gathered by testing on staging environments at regular intervals.

Packing in some good analytics within the application will also provide valuable insights into usage patterns which again can be used as feedback on the features delivered.



Reducing time to production to quickly deploy UI fixes

Another important thing which experience designers should push for and be congnizant about is how long it takes to promote a checkin to production. Often in larger organizations there are heavy processes involved in promoting a change which can be quite frustrating for designers when they want to promote small UI fixes into production over night















It is important that the whole team works towards removing any potential blockers that come in between a code checkin and deployment. The team should also constantly try to reduce the time it takes to make a deployment into production











A lot of project teams end up taking days to deploy to production which ends up being a major release overhead cost. The sooner this time is reduced, people will encourage more frequent changes to production, which again will be a great opportunity for deisgners focussing on visual design aspects to push in those minor tweaks to the UI.

Conclusion

I would like to keep this simple to say that fitting in experience design into continous delivery need not be viewed as a challenge. The many windows of opportunity are infact a boon for UXers and should slowly start encouraging them to take more risks and iterate over their design over releases, rather than be the perfectionist before the first release.

All it needs is the iterative mindset !

Integrating experience design in an Agile project lifecycle

Many organizations now employ experience designers to design products and services with a strong focus on the end user experience.

According to Wikipedia Experience Design is

An emerging discipline, experience design draws from many other disciplines including cognitive psychology and perceptual psychology,linguistics, cognitive science, architecture and environmental design, haptics, hazard analysis, product design, theatre, information design, information architecture, ethnography, brand strategy, interaction design,service design, storytelling, heuristics, technical communication and design thinking.

While it is still a relatively new and emerging discipline, it has its roots in psychology, design thinking and various forms of user research. Given this background, people playing such a role are often in a dilemma of where do they fit in , when it comes to a fast paced lifecycle of an agile project.

If not resolved early, it is easy for user exerience designers to start working in a silo with minimal interactiion with the delivery team. This is counter productive as then the UX people have no idea of the project rythm and cadence and often end up taking huge amounts of time to deliver the relevant artifacts (wireframes, visual designs, content etc...) for the project.

This can become very frustrating for both parties and the best way to resolve this is by integrating the experience design people as a part of the entire project delivery team. Having a Lean approach towards UX leads to designers showing their work at regular intervals to the team, validating it and adapting , just like a regular agile lifecycle.

What works best during the course of a project is to have the UXers also accountable for each user story just like analysts, developers and testers. If you have more than one UXers in your team, ask them to signup as a UX Owner for user stories. This means that they are responsible for taking the user story or the feature all through to production from an experience design standpoint

Accountability to a user story is quite important because it integrates the work the UXers are doing to the daily cadence of the project team which is entirely based on user stories. Based on this, a typical standup update for a UXer would be something like this

An experience designer needs to work in a similar cadence as a business analyst who is trying to get the next set of stories analyzed for development.

A lot of small UI tweaks can be fixed very quickly if the UXers were to pair with developers and testers when they are actually integrating the visual design into the application.

So rather than working in a silo, a user experience designer has to be fully integrated with the development team during the entire project lifecycle. They carry the same responsibility as others in the team to maintain the flow of stories through till they are released.

The case for reducing focus on estimation

Why is an estimate required ?

An estimate on a task, story or a feature is really required to answer 2 questions

a. How long is it going to take to build it ?

b. How much is it going to cost ?

Who really needs estimates ?

In a typical software project, there are 2 kinds of people who really ask for estimates.

1. Product Owners – They are the ones who care about what is being built in the product. When they look at an estimate, they are thinking

a. Can I really wait this long to get this feature out to the market ?

b. Is it worth building this feature given the cost ?

c. Can I come up with a cheaper option which can give me a better return on investment ?

2. Managers – They are the people who are responsible for managing the budget allocated to build a product, and also schedule dependent activities based on delivery timelines. When they look at an estimate, they are thinking

a. Will this feature be delivered within budget ?

b. Can I make commitments to other stakeholders, dependent teams, schedule other activities based on these estimates ?

Issues with estimation

1. Time taken to estimate

Teams spend significant amount of time during the project to estimate and come up with accurate estimate numbers so that project managers can plan and make commitments. This takes even longer when you are estimating in hours or days instead of light weight metrics like points.

Some project teams have multiple reviews of these estimates and even bring the estimate down to a complex formula which is worked out based on over 5 parameters for every story. A lot of time is also spent in deciding which estimation model to use in the variety of estimation techniques available in the market.

2. Accuracy of estimates

The more upfront  estimation is done for stories, the less accurate the estimates are. Estimating stories which will potentially be played 3 months down the project makes no sense because a lot would have changed in project, from the codebase to the team composition which will ensure the upfront estimates are stale. Ultimately these stories will have to be re-estimated which will again consume equal amount of time if not more, after 3 months.

3. Undue pressure on the team

Estimates which are done especially in hours or days end up putting undue pressure on the team members. Inexperienced managers push their teams to achieve the planned velocity by making them work for longer hours which ends with a team death march instead of working in a sustainable pace.

4. Time wasted in questioning estimates during the project

A lot of time is also spent questioning estimates of individual stories in the project when things are not going too well and the project is not on track. Stakeholders as well as managers start questioning estimate of stories which have a larger number against them. Some people start measuring actuals on estimates which is counter productive.

Reducing focus on estimation

1. Engage with the right stakeholders

More than the estimates themselves, it is important that the estimates are being given to the right stakeholders.

Engage with the people who 

a. Care directly about the product and the features getting built in it

b. Are directly responsible for the money being spent to build that product

It is often difficult to achieve this in large organizations which do In House IT development with multiple vendors such as banks and insurance companies. It is often easier to get the right stakeholders in a product company or a start-up.

If you are reporting estimates and progress to someone who is just a middle manager not worried about either of the above, the you are engaging with the wrong stakeholders and are wasting your time.

2. Engage with stakeholders by showing working software than status reports

Once you have the right stakeholders as talked about above, it is important that you move the engagement by showing working software frequently rather than showing status reports with estimates and burn up charts.  Show progress by showcasing new features built by the team to the product owner rather than showing how many points were completed.

Release as often as possible. Achieve a monthly , weekly or even a daily release cadence. Once people who pay the bills, see the releases coming out, they will worry less about velocity in iterations.

3. Be transparent about the processes and practices

Stakeholders start worrying a lot about estimates for each story when they are sceptical about the way the team works.  Some people start looking into the estimate of each story and question the estimate, and the team spends hours justifying their estimate. This often happens because stakeholders do not understand that the team works on a pull based work schedule where if a story gets done , the team pulls in the next story to work on, and estimates largely become irrelevant during execution. (E.g.: even if a story is given a questionable estimate of 4 points, if the team completes it within 2 days instead of 4 days, and agile team will pickup the next story from the card wall )

When stakeholders understand this model of work distribution, they know that there is minimal waste of team capacity and stop worrying about estimates. Measuring actuals in such a scenario is also a compounding waste.

4. Use relative sizing of stories when there is a need for a rough timeline and cost

The question of “How long is it going to take and how much is it going to cost ?” will always we be asked for stories, features and product releases. Someone will have to signoff on a rough budget to build the product and commitments will have to be made to people dependent on the product launch. This demands some sort of raw estimation and scheduling of work.

Given the nuances of detailed estimation, a better approach is to use relative sizing using story points and either use raw velocity or yesterday’s weather for planning.

5. Focus on reducing cycle time or business value delivered if a KPI is needed for progress

There might be situations when a metric is required to track progress as a team, and if that is required, focus on reducing cycle time to delivering stories to production. Another good indicator is the amount of business value delivered in a period of time by the delivery team.

Conclusion

Software industry has moved from an era where teams did  upfront analysis and design for a quarter of a year before development began, to a much more iterative development model quicker release cycles since the wide adoption of the Agile manifesto. With the advent of cloud computing and continuous delivery it has now become cost effective to deliver frequent releases to production every month/week/day. This has left software estimation irrelevant over a long term. Estimates will still be required to give a budget and a date commitment to clients, but with there exists a strong case to focus lesser and lesser on estimation.

The end of regression, stabilisation,hardening or release sprints

A lot of seasoned agile project managers have always included a stabilization  or a regression/release iteration before planning a release of their project. This has been a common norm for the last 10 years. A typical regression/stabilisation phase may last a couple of iterations for every 4-6 development iterations of a release.

 

The reasons for a regression/stabilisation sprint (s) is to 

* Allow quality analysts to regress the system by performing  end to end testing of the application rather than focussing on specific features or stories.

* Allow quality analysts to test the system in an actual production like environment  with all the 3rd party interfaces the system interacts with.

* Allow developers to fix any regression defects arising out of this kind of testing and getting a stable production quality build which one can go live with.

 The problems with this approach is that it is highly unpredictable because of the following

* There is often no reliable way to predict the length of these sprints upfront. These sprints often end up being a time boxed effort slotted in the planning diary towards fixing defects arising out of regression. Managers then spend huge amount of time generating defect reports, classifying them based on severity and priority, triaging with customers endlessly to keep the stabilisation sprints under control.

* The cost of fixing end to end regression defects so late in the development cycle is very high, if you were just focussing on fixing story/feature defects in your development iterations. This again makes the length of regression sprint unpredictable.

* You find issues with production environments and your deployment scripts when you are about to deploy on a production like environment. 

The easy way to end these unpredictable regression sprints is to regress the application continuously, by deploying continuously on  a production like environment. If you have invested in a good automation test suite and have been maintaining it for a long time this is a good first step. The next step is to automate your deployment infrastructure over various environments such as Dev, UAT and Production, and ensuring that your configurations across these environments are well tested. Jez Humble's book on Continuous Delivery has an exhaustive account of how to achieve this in projects.

It takes a lot of investment in terms of time and effort to reach such a stage of continuous automation and deployment into production. However you can start by taking smaller steps towards it

1. Try moving the definition of done towards the right side of the card wall as much as possible. If you count a story as done when it is QA tested, try moving it to Showcased or Automated, or even Deployed. Count velocity only when a story reaches that state.

2. Start automating every manual step you see on the path to deploying a story and automate it one by one. You can even plan this during your iteration planing meeting by focusing on automating at least one deployment step. (Think Kaizen)

3. Ask developers to start adding at least one acceptance test in addition to the unit tests which drive a story, before they call a story development complete. Ask QAs to do something similar

As a  project manager you should be able to answer reliably (with minimum ifs and buts) the question of "How long will it take us to make simple code fix and take it all the way to  production ? " .  Having the unpredictable regression sprints out of the way as soon as possible is a big step in being able to answer the same.