“Live Long and Prosper”: Customer and Employee Retention with an Agile Process
Rodney Guzman
InterKnowlogy
June 2009
Summary: This article profiles the evolution of a professional- services company this is focused on software- application development.
Contents
Introduction
Make the Customer Your Ally
The Actors
Developers, Developers, Developers, Developers
Becoming More Efficient
Task Estimation
Project Execution
Conclusion
Introduction
Building software is an art. But like a building, a well-built piece of software will stand the test of time without constant upgrades and maintenance. Unlike construction, however, each building that you create is unique. If software developers cannot cookie-cutter their software applications, much like tract homes, how can they become more efficient? Being more efficient allows us to create higher-quality software in less time. And less time means less money. From building libraries of reusable controls to executing an agile-development process to growing employees with the help of mentors, every aspect of software development can be improved to lower the cost of software creation.
This article is a profile on the evolution of a professional-services company that is focused on software-application development. Over the past 10 years, this company has had to become more efficient to remain competitive and unique in a market that has commoditized many aspects of its offerings. Many hard lessons were learned, but what has emerged has allowed the company to continue to thrive even in today’s economy. At the core is a hybrid agile methodology that is used to deliver everything from enterprise-size applications to one-week demo applications. This is powered by like-minded software and system engineers, as well as project and engagement managers.
Discover the process that this company uses today to build its software consistently on time and on budget.
Make the Customer Your Ally
Your customers can be extremely diverse, having very different backgrounds and expectations on how custom software development is performed. Or you might be lucky and have only internal customers who are intimate with your software-development process. Regardless, your work will be remembered by your ability to hold to your word of when what you say will be delivered is delivered.
What must be acknowledged is that no matter the quality of the technical solution that you produce, success will be measured by how you meet the expectations of your customers. The process that you use to create custom solutions should actively engage the decision makers who will be passing judgment on whether or not the outcome is successful. Your customers should never be surprised or embarrassed. They can be surprised because the feature that they thought was going to be developed was not developed, or a deliverable was late and they did not know about it ahead of time. They can be embarrassed because promises that they made were broken, due to a feature not being delivered when it was supposed to be delivered.
Custom software development can take on a life of its own after the project has begun. It is well known that it is quite impossible to detail every requirement of each feature before any code is cut. Gone are the days in which weeks (or even months) are spent on requirements documentation that quickly becomes obsolete during the project. The software industry has been alive for a long time now, and your customers are much wiser. The concept that the features mature as the project progresses is not foreign, and your customer will expect you to be able to react to change during the project. Keeping the customer engaged and part of the decision-making process for these changes is what must be done.
Everyone knows that change will occur during the building of a custom solution, new features will be born, and priorities will change. Embracing this fluidity and immersing your customers in it allows everyone to be on the same page. When your customers want a new feature, it will be placed on a feature backlog that is to be built. A priority will be assigned to it and an acknowledgement made by everyone that without a change in scope or timeline, other features will not be developed in the final deliverable. By allowing your customers to change priorities during the project and helping them understand the ramifications of performing that action, they become part of the solution and will become your ally.
Your customers will feel enabled by being able to affect the project. They should be kept engaged with status meetings as frequently as you can (for example, twice a week) in order for them have a constant pulse on the project, and not by weekly status reports that no one ever reads. If they are part of the creation process, and not just there to receive the deliverable at the end of a sprint, your customers will already know what will be delivered to them before they see it and they can actively set expectations on their end. The risk for performing rework to appease a customer is significantly reduced, you complete the project when you said that you would, and your project team can be released on schedule to work on another project. Your customers will ask you back for repeat business and will be a reference for new customers.
It can be perceived that what is being endorsed here is a recipe for a never-ending project, which could not be further from the truth. The goal of the process is to guide the airplane that is your project to a scheduled landing in one piece, entirely intact, and as close to as what the customer wanted. The fact that some details might be missing from the final product will have been a decision to which your customer has already agreed.
The Actors
People make the process run. Certainly, there are such software tools as Microsoft Team Foundation Server that enable the process, but one cannot expect to become efficient and organized by just installing and using a product. There are key actors in this dance who allow an agile process to function: project managers, developers, and—for lack of an industry-accepted term—engagement managers.
The Job that Few Want and Even Fewer Are Capable Of
Many developers view project management as a necessary evil. It is apparent that the expectations of a project manager (PM) vary tremendously from company to company. Here, they help bring order to chaos. They are the unsung heroes of delivery and are leaned on by the developers to be the bad guys. They ensure that no detail is left undone and hold both the development team and customer accountable.
After the project has begun, the PM is the main point of contact with the customer. The PM brokers all conversations with the customer (including being CC’d on all e-mail messages) and is the final decision maker for anything that can affect the schedule and scope. The developers are shielded by the PM from the political minutiae that often occurs during the project. The PM initiates and facilitates conversations with the customer when the developers want to push back on how a feature is interpreted.
Constant communication is the mantra of the PM; protection against misinterpretation of these communications is paramount. Each non-written communication can result in key decisions being made and the scope changing, as well as actionable items upon which the team is relying in order to meet the interim deadlines. These interactions must be documented and echoed back via e-mail to all of the participants in order for everyone, including the customer, to understand how the team interpreted the conversation. The first time that you must lean on one of these e-mail messages to show why something that the customer did not expect occurred during the project will be the last the time that you need any evidence that this is a worthwhile activity. Not having this to lean on is much worse and could cause you to make up, on your dime, the time that is necessary.
For the team, the PM will monitor the progress of each interim deliverable. Progress should be measured on a daily basis, as interim deliverables (to keep the customer engaged at the appropriate level) are delivered every one to two weeks. Your developers should report their hours at the end of each day, in a way that will show how much energy was put into their tasks and how much more time they estimate it will take to complete it. Each morning, your PM can gut-check the cadence of the project and the momentum that is being made toward the delivery of interim milestones. Minor course corrections—such as providing additional help to developers, so that they are not spinning their wheels—can be made on a daily basis. Keeping everyone moving toward the interim deliverable is the job of the PM.
Developers, Developers, Developers, Developers
For an organization that creates custom software, nothing is as expensive as replacing a developer. The process is designed to protect the developers from outrageous commitments, miscommunications between the customer and the team, and consistently working long hours. Fostering a climate of constant feedback, participation, and ownership will quell feelings of hopelessness and simply not caring about the outcome of the project.
Many developers wield superhuman powers when it comes to how fast they believe they can accomplish tasks. Too often, they do not account for the time that it takes to discuss details, have meetings, write documentation, unit-test, and deploy code. Just as you should include your customer as an active member of your project, so should you include your developers. Providing the entire team with a sense of ownership of the deliverables is what you should strive toward. For developers, ownership can be obtained by allowing them to perform estimates for their tasks. At first, their estimates will be way off, and they will pay the consequences of working longer hours to make up for it. With just a little experience, they will learn to provide estimates that are much more accurate.
The end result is a sense of ownership of the deliverables, and this fact cannot be overstated enough. This is software development, after all, and not everything always goes according to plan. Sometimes, additional effort is required to get the train back on track. The process of constant communication between the team is designed to catch the train before it fully derails. However, team members will sometimes need to work extra hours to get back on track. If they own it, they will be much more likely to want to fix it.
On each project, there is one developer who has a special role:
This is the technical peer to the PM. This person leads the team of developers and is responsible for the design, architecture, and development of the more difficult portions of the project. Code standards are enforced by the lead, who mentors the development team and provides code reviews as needed. The technical lead reports to the PM and, without consensus with the PM, cannot stray from the tasks that have been agreed-upon. Your customer will often form a special relationship with the technical lead—sometimes, even trying to circumvent the PM by going directly to the lead. The lead is responsible for ensuring from the team estimates that are as accurate as possible.
The People who Buy Lunch
The role of an engagement manager is to form a relationship with your customer that spans all past, current, and potential future projects. More than a salesperson, these managers understand the customer business and the technical details of what is being delivered. They receive honorable mention here, because an engagement manager is the one person who the PM and technical lead can leverage to persuade the customer to align expectations with the team. The fact is that not every detail of your project can be documented. Many conversations, agreements, and understandings that never make it to paper are formulated when the project is first envisioned.
The engagement manager is the constant reminder to the customer of all of the past discussions and agreements, and will keep the spirit of the deliverable alive that was agreed upon when the contract was signed. This is acted upon during customer meetings, which the engagement manager always attends. The technical lead and PM work closely with the engagement manager, so that preemptive strikes can be made to manage the expectations of the customer. This is an active process that is an insurance policy on keeping the deliverables on time and on budget. The triad of the engagement manager, PM, and technical lead is the team that constantly manages the expectations of the customer and actively works together to keep the deliverables to the timeline and to the budget.
Becoming More Efficient
You should expect your process and your people to become more efficient. Process refinement is not something about which you will meet every quarter to decide what to change; it should be done at the end of each project—sometimes, facilitated by a lessons-learned meeting. For example, you might decide that you should categorize your tasks in a more standardize manner from project to project, so that people can think about how they will the organize projects more consistently. Or you might begin to see patterns of blown estimates in your projects, which should be acknowledged in your lessons-learned meeting.
For example, drag-and-drop touch-based functionality is hard in Windows Presentation Foundation (WPF). By putting metadata on your tasks to classify the type of feature that it is, such as drag and drop, you can report on these more effectively across multiple projects. By having a greater understanding of your risk areas before you start a project, you would be able to make strategic decisions on whether or not to accept those features, or provide a proper estimate to accommodate for it. These are just some simple examples of how to make your process more efficient. But the real improvements that you will see are by making your people more efficient.
All individuals bring their own unique strengths to the project. Knowing what those strengths are and how to maximize the potential of each person comes only from working with the sample people over a period of time. The investment of bringing new people into the fold is not quantifiable, but it is felt by everyone, so that retaining the quality people that you have is extremely important. When you are running a project, putting people in roles and giving them tasks at which you know they will not fail is critical; no one is demoralized more by being set up to fail. This village knowledge of what everyone brings to the table happens over time. Your efficiencies will come by being certain that everyone is aware of your strengths, the strengths of your team, and the weaknesses that people want to fortify. Asking someone to become better at something in which they have zero interest is a recipe for frustration.
Technical efficiencies also should be gained over time. Developers will get better at their craft when they see more and more projects that reuse the same technologies and tools. They will see architectural and design patterns in their projects that they can leverage from one to the next. Best practices will become second nature. Developers will get better at asking the right technical questions ahead of time to reduce risks down the road. However, the technology suite of today is so vast that no one person could be the master of all. Your developers will need to be focused in one area, such as WPF, in order to become masters of their craft. Asking a developer to dabble across all technologies can be done, but gaining efficiencies is much more challenging, because patterns that are evident will no longer be so.
Employee retention is key to becoming more efficient. Developers can be fickle beasts, and they must be constantly challenged and inspired. Consider the scenario of running a large 12-month project in which your best developers are engaged. This team is stuck with the same customer, solving the same business problems and having very similar conversations for a year. The technology could be cool, but everyone gets into a groove after a few weeks, and each week feels like the last. To keep these people inspired, consider reserving a handful of hours each week to allow the entire team across all projects to collaborate together on projects of their choosing. This type of freedom will liberate them from feeling lost in long-term projects.
This time will become the most precious thing that you can give to your developers. It will boost morale and help employee retention.
Task Estimation
There is no book, class, or training that will make you good at estimating. Every piece of work that you will estimate has unique nuisances that cannot be cookie-cut from project to project. Certainly, the approach that one takes to estimate can be standardized and book-learned, but knowing when a project will take longer (or example, because of a demanding customer) comes from experience. The challenge is to ensure that enough time is being allotted to the project to accommodate the fluidity that naturally occurs and that you want to promote.
When the project is first discussed with the customer, many features must be called out with assumptions and risks identified. Before a contract is signed, consider documenting this information formally and providing it back to the customer to ensure that there is a common understanding of what is going to be built. This will provide additional touch points with your customer and allow further conversations to be had and trust to be earned. The person who is authoring this document will most likely become the engagement manager for this project. The details of this document can make their way into a contract that you would sign with your customer.
As soon as everyone is on the same page, but before a contract is signed, an estimate must be created. Have as many eyes involved as possible at this point. Ideally, you would include the PM and technical lead who would be running the project in this part of the process. A sense of ownership of the deliverables for the agreed-upon estimates will be derived from their involvement in this part of the process. In contrast, if an estimate is performed in a vacuum without proper participation from the team, something can be easily missed, and the project turns into a death march. The engagement manager will become extremely unpopular by pressuring the project teams with wrong estimates.
The milestones and schedule of the customer are factored in.
An attempt might be made to run the development team as small as possible to avoid the inefficiencies that larger teams can have, but sometimes inefficiencies cannot be avoided. The schedule might be more demanding and therefore warrant a larger team to complete the work more quickly. The number of developers on the team, combined with the read of the engagement manager on how difficult the customer is to work with, factors into how much project-management time will be required. There might be additional resources, such as an artist or quality-assurance engineer, that must be factored into the estimate. Your own weighting factors for these additional types of resources must be developed. For example, for every 100 developer hours, you might 10 ten artist hours.
When development hours are derived from the identified features, it is difficult to accommodate everything that occurs around software development. This includes frequent meetings to discuss design and architecture, unit testing, and code reviews. To formulate a weighting system that is appropriate for your organization, use your past projects for the forensics on how long it took you to develop a feature versus how long you estimated that it would take. When you think about how long it takes to develop a feature, think of it in raw developer hours—without the meetings and so on. When the raw developer hours have been captured, factor in a weighting for the additional items that make your process work.
The type of project will factor into the weighting that you utilize.
A production quality application is different from a proof-of-concept or demo application. A proof of concept does not need the same rigor as a production application. For example, corners can be cut in the architecture and design for a proof-of-concept application, and you probably will not need the same level of unit testing and documentation.
An estimate is only a guesstimate that is founded on the experience of many. Be prepared to make mistakes on the road to getting better at estimation, but set yourself up with the ability to learn from your mistakes. Review your estimates with as many people as possible before you commit to them. Use the process to hold the expectations of everyone to those estimates. Sometimes, mistakes will be made, and only longer hours will accommodate it. The goal is to drive these incidents down to the point at which they are anomalies and not the status quo.
Project Execution
Agile process is about keeping things simple, communicating every detail, and getting work done as quickly as possible. There is a simple formula that you can follow to streamline execution of your project. Every step of the process is intended to be action-oriented and produce tangible results. You are not expected to waste time in long meetings or writing novels of technical documentation; your focus is on building software quickly, in such a way that everyone (including the customer) has deep awareness of the direction of the project.
Kickoff
By the time that developers start learning details of the project in an official kickoff, many ground-setting actions have already occurred. The engagement manager, PM, and technical lead have already formed an action plan. The triad has received the customer-signed contract and might already have had numerous impromptu meetings to discuss the details of the project. Expectations might already have been set with the customer on what high-level features must be delivered, and when. The triad now must deliver the details to the development team. This will be most likely one of the longer meetings that you will have.
Different features are discussed by the technical lead. From the available resources, your technical lead should have asked for people who would be best suited for the technology that is being used on this project. High-level feature areas—such as different groupings of screens, Web services, and data sources—are called out in the meeting. People are assigned to the different feature areas. During the meeting, if it is appropriate, you can let your developers talk amongst themselves and decide. When developers choose the work on which they will work, a sense of ownership of those features is derived. As with the estimates, strive to promote a sense of ownership throughout the entire team, at all levels.
When feature areas have been assigned, you are ready to switch gears into creating a feature backlog and sprint-planning discussion.
Planning
The PM, technical lead, and (potentially) development team will meet to create as comprehensive a feature backlog as possible. A feature backlog is a list of features that is shared with everyone and that will be built in all of the development sprints. Based on everyone’s understanding of customer priorities, a priority level is assigned to each feature in the backlog. Additionally, features that are dependent on one another are called out. Riskier features are tagged as high- priority items that should be completed near the beginning of the project to avoid dependent complications down the road.
When the feature backlog has been completed, it is reviewed with the customer for completeness and accuracy. The customer can choose to change the priorities at this point and ask for clarification on how the features were documented. There is a tipping point here, when a customer sees the feature list and has a deeper understanding of all that they are going to get for their money. A comfort level is maintained with the due diligence that your team has already performed during the contract process, and is affirmed with a feature backlog list.
This honeymoon stage is the perfect time to discuss how low- priority features will be handled; this where most of the fluidity will occur during the project. There are low-priority features that simply will not make it into the final deliverable. The team will do its best to do this, but it simply will not happen because of its being unplanned during the project. Low-priority features will be scheduled with the related higher-priority features in a sprint, because it would make sense to complete them while working in related areas. If a low- priority feature does not get completed in a sprint, it is rescheduled to another sprint. In order for this to work, your customer must be engaged within the sprint to see why a low-priority feature did not make it into the sprint.
When the feature backlog has been agreed upon, the features for the first sprint are identified. The technical lead works with the development team to break into tasks each feature for the next sprint. Each developer who is assigned to a feature area, in conjunction with the technical lead, develops a task list. The technical lead attempts to standardize the tasks that are created in terms of how they are worded and their duration. Strive to make your tasks no longer than a single workday, as you will want to be able to measure progress of a project at a daily level.
There is a lot of back and forth on the estimate between the developer and technical lead. Your technical lead was already involved in providing a higher-level estimate and has a good pulse of how each feature should be developed. When the technical lead and developer are in agreement with the estimate, a sense of ownership of that estimate is derived from the developer, because the developer had a strong hand in developing it. These interactions can occur in a group style, so that each developer is aware of the details about the different functional areas and will be able to better meet the expectations of the technical lead when it is the lead’s turn to help provide a task list and estimates.
During this planning phase, multiple things have occurred to better help you deliver your project. You have further endeared yourself to your customer, who has now been exposed to the details of how the software will be delivered. You have also endeared yourself to your development team by having them participate in the planning process. Both will help when dealing with the unplanned. You will be able to lean on your relationship with the customer when things get rough, and developers will go that extra mile without asking to get things right. This will only assist you in delivering your project on time and on budget.
Sprints
A sprint is a focused effort by the team and customer to produce interim deliverables that can be reviewed. A sprint could be two days long or two weeks long, depending on the features that have been identified. At the end of a sprint, a deliverable is handed to the customer. Sometimes, there is very little to show from a user- experience perspective; but handing over a deliverable to your customer is still paramount to keeping their trust.
At the beginning of a sprint, developers know what is expected of them to complete their features for that sprint. When the sprint kicks off, developers communicate the order in which they will be completing the features. Any dependencies between developers are called out, and the technical lead can choose to reorder the features within the sprint.
Each day of a sprint looks and feels very similar. The team comes together for a brief meeting to discuss what was accomplished the previous day, what will be accomplished that day, and any risk area that has been identified. If further discussion is required on a particular item, a separate meeting spinoff occurs with affected team members, so as not to waste everyone else’s time.
At the end of the day, developers are required to report what hours were spent on what tasks and how many remaining hours they have on those tasks. The PM examines these hours and discusses them during the brief meeting. This gives the PM a sense of the cadence of the project to ensure that the deliverables for the sprint are on track.
If it becomes known that a low-priority feature will not make it into a sprint, a discussion with the customer occurs in one of the status meetings as soon as possible, in order for everyone to participate in that discussion. This is not necessarily a common occurrence, and it typically should be avoided in the first sprint, just so that the customer does not come to believe that this is normal.
Conclusion
Building great software requires not only a development process, but also a process to manage your customers effectively. The process is powered by people who are bought in and who believe that following it produces results, reduces chaos, and allows them to succeed. Managing the expectations of the customer is as important to the success of the project as the technology work itself. Having the right people in the right positions who love what they do makes the process work. Focusing developers in a technology area allows them to breathe the same issues, solve the same problems, and see the same patterns.
Ownership from everyone is key to promoting a well-running project. Your customers will be willing to make sacrifices during the project, because you have empowered a relationship with them through your process. When you need them to, your developers will go that extra mile when the time comes. No software-development process or plan is perfect, because no project is the same as another; each is a custom piece of artwork. Your process should embrace this uniqueness of each project and the changes that naturally occur during it.
About the Author
Rodney Guzman (rodneyg@interknowlogy.com) is the CTO and cofounder of InterKnowlogy.
Follow up on this topic