Agile Methodology, Customer Experience, Nearshore, Product Development, Project Management, Successful Outsourcing
Work is always measured in some way. If you are doing repetitive work, the tendency is to measure the number of repetitions, like the pounds of fruit picked by a field worker in an hour or a day. If you are doing knowledge work, the tendency is to simply measure hours of work spent on the problem, assuming that a) the person doing the work has the necessary set of skills and a comprehensive knowledge base of the subject at hand and b) they spent enough time to evaluate the problem sufficiently and provide a balanced solution. If you are doing time and/or payment-dependent contract work, the main consideration is did you complete the work assigned in the contracted period and at the specified cost?
This all seems relatively benign and normal in the world of work because it assigns a value to work that can then be measured and evaluated in various ways. Did you pick more fruit this week than last? Did you solve more problems in this quarter? Did you complete all your contracted work on time and budget?
Software development is, of course, one of the most valuable types of knowledge work being done globally today. Since development is usually the domain of teams and is at this time, largely done with some form of agile and/or lean methodologies, the measurements tend to be a combination of individual and team metrics applied by various means. Some common metrics are:
When we get beyond these three common methods and their minor variations, we start getting into more complex models (!!) that tie team performance, quality, project length, man-hours, adherence to production and methodology standards and complex team models in DevOps implementations.
We Have Questions
At the end of the exercise, however, it is done, we end up with some sort of measurement of the work of software development. But as we do, we need to ask ourselves a few important questions:
What does our measurement tell us? What is it not telling us? If we are measuring lines of code or functions, is the measurement telling us if the work was efficient or just an output meant to produce more (or a given number of) lines/functions over a given period? Were the lines of code or functions really efficient and useful? Programming is very comparable to writing. Some writers are more efficient at expressing thought and others see a more elegant way to express a thought without addressing it directly. Some programmers are more efficient because they reuse code multiple times throughout the source with efficient use of variables. Some functions in a program are critical and getting them right is tough, requiring time and effort. Other functions are simply «eye-wash» and don’t have a real bottom-line value. There as many ways to game the system as there are ways to produce better code with fewer lines. Every programmer, every team, and every project has different dynamics depending on the language being used, the type of environment, the technical problem being dealt with and many other factors. If you use a pure «number of X metric,» you have to be clear about what it means and doesn’t address.- Is our measurement comparable? Can it be used over the long term or compared across projects or teams? Frequently, this is where the complex math becomes part of the equation and frankly, begins to fail to do its job effectively. The more we try to «normalize» measurements across a single project, between teams, and across projects and teams, the more subjective the outcome becomes. Were the technical hurdles encountered at the beginning of Project A really comparable to Project B? If we decide there is a significant difference, how do we adjust for it? Did Team A experience more changes in team composition than Team B? How do we account for that issue? Are we comparing skill levels, experience, time to reach «normal productivity» or some other factor? Was Team A really suited to provide the skills and experience needed for the given project? Did their productivity fail to reach the levels expected because of issues outside of their control? In most cases, the more you try to normalize between measures of productivity between individuals, teams, and projects, the less sure you can be you have a reasonable common measure. And in the end, the question becomes, is a comparable metric what we really need?
Isn’t any measurement better than no measurement? Can we afford to fly blind? Certainly, if you have an outsourced team, multiple teams, and/or multiple projects you have to begin to understand why some projects seem to work well and some don’t. You need to be able to judge if a project is going off the tracks so you can get it back in line before the problem becomes critical. Finding ways to measure performance and productivity would seem to be the best tool to address the common issues in software development projects. But if the measurements we are using aren’t really addressing the problems we have, how are they helping us? Are they really more than just busy work for managers and bean counters?
The more we look at the problem, the more we begin to understand that measurement for the sake of monitoring «something» isn’t really useful. But on the other hand, measuring any aspect of software development is better than monitoring nothing at all and simply hoping everything will work out in the end. Even a weak measurement provides some level of confidence if it is used consistently and we understand its shortcomings well enough.
In agile teams, there is another, more important way to look at things. If we give the team simple methods they agree on and understand, like story points and burn down charts, they will know when they are performing well and when they are pushing too large a boulder up a hill. Inside the team, they know who is consistently performing and producing efficient code with fewer problems. The team knows when its backlog is too great to finish in the allotted time. Team members learn quickly who can be asked for pointers on how to approach a problem properly and who cannot be depended on reliably. We can stand around, pointing out issues with the common ways to measure agile team performance, but their value is those common agile methods are basically useful to the team to understand where they stand in relation to the work ahead of them and their quality performance. Where we get into trouble is when we try to extract the common measures and try to draw larger conclusions from them.
The Reality is – Communication is the Key
If we get past trying to use performance metrics outside of a single project and narrow our focus to what they do for a team inside of a project, we begin to see their value more clearly. The team knows what is going on. They may attempt to fool themselves or others, but in the end, they can see the light in the tunnel and they know if it is a successful end to the project or an approaching train. The problem is to get them to trust each other and the larger team enough to surface the problems they see as soon as they see them, without fear.
The level of trust and responsibility required for open communication and collaboration is perhaps the largest problem faced in software development projects. It is the «why» behind the invention and popularity of the agile and lean methodologies in wide use today. Conversely, the larger the organization, the more critical and costly the project is to the organization, the less likely it is that the team will feel and be enabled to inquire and speak out about the problems they believe they are facing. In a large organization, metrics are the shorthand to avoid having «high touch» with every team and individual. In a costly, critical project, metrics are meant to be the «truth-tellers» to assure stakeholders that things are well controlled, even though everyone knows that metrics can be gamed without much problem. And the more the metrics are relied on, instead of the knowledge inside of the team, the more likely it is the project will get out of hand before the problems are addressed.
Responsibility. Trust. Communication.
So what is the bottom line on measuring performance and productivity in software development projects?
- Measurement is most useful inside the software development team itself,
Planning Poker
where the knowledge resides about what is really going on from day today. Everywhere else, it is just as likely to be smoke and mirrors as it is, to be honest, and useful – depending on who is using the metrics and for what purpose. If the team doesn’t understand the metrics applied and can’t use them to better understand where they are in relation to the work to be done, their quality performance and general efficiency as a team, the metrics will fail to give back their primary value – keeping the team and project on track.
-
The agile methodology relies on individual and team responsibility, trust and communication. If these three points cannot be achieved within a team, agile and scrum are just a bunch of processes and procedures that may or may not be helpful in organizing work. If the team is just «going through the motions» in taking responsibility for tasks, assessing and managing their backlog, and participating in standups and retrospectives, additional metrics and measurement will not provide much value. They will provide information to a larger audience too late to enable outside forces to do more than triage injuries to the project.
- Working through what may appear to be problems or what may seem to be a simple solution requires peer-level coaching and communication, not blame. If we understand that the team itself really knows what is going on – getting them to assess the problem honestly and figure out how to address it requires something other than pointing fingers, avoiding issues and top-down communication. It also means that the team needs to take responsibility, as soon as anyone recognizes a problem could be on the horizon, to consider it seriously and determine both the size of the problem and solutions that could be used to address it. And so what if the team raises an issue that may turn out to be nothing of great importance? We’ve been called to action to look at it and we will all come out of the conversation wiser. If everyone in the conversation addresses each other as a peer, rather than hierarchically, there is a good reason to think that the next time a problem is encountered or perceived, it will be openly addressed, rather than swept under the rug.
Three points to consider and use in conjunction with standard agile and scrum-based tools. You can use more and you can draw all sorts of conclusions from the systems you bring together. But in the end, if they don’t bring immediate value back to a current project, what value are they really serving?
Looking for a development team? Contact us we can help you!
Scio provides nearshore software development services for our client base in North America. We work closely with our clients to ensure that the projects we are involved in have the level of communication and understanding needed to reach successful outcomes. If you have a project where you think we could help, please contact us. We would be happy to discuss your needs.
Agile Methodology, Customer Experience, Nearshore, Product Development
Common Myths & Misconceptions for Distributed Agile Teams in Software Development
Throughout this series, we have explored some of the best practices for agile-scrum teams, but in the light of distributed team situations. Scio provides software development teams – working from our development center in Morelia – for projects throughout North America. Our practices, methodologies, and culture are tuned to distributed team situations in a nearshore deployment. We discuss the realities of outsourcing and distributed teams with our prospects and clients on a regular basis. As we wrap up this series, let’s discuss some of the common myths and misconceptions that we hear about frequently.
There is no additional overhead for projects using distributed teams for agile-scrum projects.
Reality: Shared vision, communication, strong procedures, and planning are part of the required overhead for working smart in a distributed team environment. But, the truth is – these same elements should be part of any software development project to ensure success. While a distributed environment requires more rigor and attention to details, all projects benefit from addressing these issues.
More specification must be done at the start of a distributed team project
Reality: Increasing the upfront development of specifications for an agile-scrum project creates a false sense of security and understanding. When something needs to change, there will be latent resistance. There is an increased focus for the full team on understanding where the team(s) are and assuring knowledge is shared – but that should be a normal part of communication in any situation.
Distributed teams cannot do agile and scrum
Reality: If teams are able to organize independently, are cross-functional, collaborative, etc. – there is an overhead in coordination between teams (scrum of scrums) but mitigation in the form of improved awareness of the state of tasks can keep it to a minimum. It is much better to spend resources on coordination than fixes because one team went off the track, wasting time and resources.
Distributed teams have lower quality, more redo’s
Reality: If teams are cross-functional, managing their own tasks and backlog, enabled to work directly with the product owners, have a full development environment using test-driven development, continuous integration and practice regular builds on the central repository for the project, a great number of problems can be avoided. Regular team-wide meetings for planning, pruning, technical issues are overhead, but they will lower impediments greatly if done with openness and trust.
In larger projects, it is better to work as one team than two or more smaller teams even if some members are not co-located with the majority of team members
Reality: The communication and planning overhead does not go down in one larger team in comparison to two or more smaller teams, it rises. Size matters – smaller, self-organizing teams are more efficient overall. Team members in a larger team have less push to be individually responsible and to participate actively in the project. They can easily «hide» in the larger team. In larger teams, the overhead for work review actually climbs, because of the number of people who have to be informed and communicated with. And if the «larger team» is composed of remote members without properly recognizing them as distributed teams or single outside team members – the adherence to standard methodology, processes and assurance procedures tends to drop dramatically. They are literally «out of sight, out of mind.»
There are a lot more things that could be said, but the bottom line is – best practices matter in all agile-scrum projects. Agile is not a license to operate without structure – quite the opposite. It depends on individual responsibility, communication, and adherence to the processes and methodologies adopted by the project team. Agile is adaptive. It will scale along with scrum to situations with distributed teams. Teams that adopt the practices and procedures necessary to be successful in distributed situations as a part of their regular work patterns will have better results in all situations.
We hope this series has been useful and informative for you – helping you to understand what is «behind the curtain» in successful projects and some of the lessons we have learned in the field. If you have a project that you believe could benefit from a team that understands how to leverage agile and scrum in a nearshore implementation, don’t hesitate to contact us.
Agile Methodology, Customer Experience, Nearshore, Project Management
Organizational & Team Best Practices
In the previous article in this series, we started exploring the general organizational and team best practices for agile-scrum projects. In this article, we’re going to finish up a few basic issues and then move into points for distributed teams specifically.
As we have said, the main issue to be considered for software development with agile-scrum teams is communication. If communication is in any way blocked or stifled by cultural or organizational constraints, the team and the project will suffer. In a very real way, knowing how far along the work is on a given user story is part of that communication. We discussed building the technical elements of a system for test-driven development and continuous integration for projects, but there is an organizational element too. Team members must feel these tools are a part of their obligation to their team. They must use them religiously and fully to ensure the tools are doing the job of maintaining code and the development process for all team members. Here a few simple rules to live by:
- All development team members should check work into the common code base as frequently as possible.
- Automated, continuous builds should be run hourly with full logs turned on.
- Each individual team member must exchange a clean build by the end of their shift. Avoid situations where an individual is allowed to push multiple builds outside team core hours that could take planned work or tasks off course.
- If a specific development issue is to be addressed outside of core hours by developers, ensure the scope, limitations, and boundaries are clearly negotiated with everyone and adhered to.
Distributed Team Best Practices
When a software development project is based on distributed teams, some specific organizational practices need to be considered. It isn’t enough to just set up groups in a couple of places, and expect everything to work like it did when you were all sitting in the same big room and able to just turn around and see your teammate.
The first point to consider is how each distributed team in the project will work. One common practice is to put all the QA (as an example) in one team and to have another team be just developers. The problem is – when locations are role-based, they tend to lose overall team collaboration and become an island to themselves. The tendency in this situation is to move to an «us against them» mentality. To avoid this, set up fully cross-functional teams that have their own user stories and backlog. It promotes the team and individual responsibility and gives them a clear role in the project as a whole.
With that in mind, there are a few additional points to consider:
- Use feature-based, rather than component or layer-based teams because it ensures teams continue to have a feeling of being integrated with other teams with shared vision and knowledge. It also allows them to be more flexible if the project changes. They can take on a different backlog because they understand where the project is going.
Distribute work evenly – don’t allow one team to sit fallow while another catches up. This, of course, implies that regular discussions of workload (a scrum of scrums), dependencies, and assumptions is critical to the balance on the project as a whole.- When a team has a local «proxy» for the client-side product owner, it is critical that that proxy role has daily contact and communication with the core product owner to assure they can make decisions quickly and with the assurance they are in sync with the current vision.
- Each team must feel enabled to clarify issues directly with the client side (they have their own user stories – remember…) and not be tied to a chain of notification. Invariably, notification chains shorten messages, misunderstand the context, and create communication loops that just slow down clarification and decisions.
- Teams must have daily points of contact between them (scrum of scrums again) to discuss progress, dependencies, impediments, etc. and assure product owners are not being quarried about the same issues multiple times.
One Team Member «Outside»
There are times when it is necessary to have one lone team member outside the main development group or even a couple of individuals remotely located by themselves. This is not an unusual situation, but it is one that takes care to handle properly. All the work you do to assure a cohesive, collaborative team can be lost when one remote member is not paying their role and participating in the process properly.
In basic terms, all the distributed team and organizational best practices apply except:
- Single development team members cannot be a stand-alone unit in the same way a minimal team can – so they need to be formally paired with other team members in a way that assures they will remain «in the loop» throughout the project. To make this work, consider pair programming (especially early in the project) and pairing with a specific QA.
- Avoid situations where single team members are outside of the team core hours more by more than one or two hours. Longer isolation will simply assure they will not integrate easily with the rest of the team – they will remain the lone wolf on the outside you have to watch constantly to assure they don’t go off course.
- «Standard practices» (development environment, burndown chart, shared repositories, active participation in meetings, communication systems, etc. become critical resources to assure the remote team member feels they are a fully integrated and vital part of the project. All aspects of processes must be proven, clearly documented and relatively easy to setup and use.
- If the remote team member is new to your procedures and processes, have a standard initiation program as a part of the project initiation or before. The program should include not just the setup, practices and methodologies necessary to understand the way the team will operate. It should also include the reasoning and expectations they as a team member will operate under.
The single team member working remotely deserves some special consideration. They must feel they are part of the organization and able to be productive in their environment. For that reason, it is important to consider if they are working from their home, what kind of set up they have. Do they have good networking? Do they have a regular work area with good ventilation, light, and isolation from distractions? A worker at home, with the TV blaring in the other room or perhaps a baby that requires attention on a regular basis is going to find it very difficult to be as productive as their teammates. What can you do to assure they are not at a disadvantage? Consider issues in the same way you would any impediment in agile development – what can you do to move the impediment out of their way?
The Take-Away
In the end, it should be easy to see that that making an agile-scrum project successful with distributed teams is nothing more than doubling down on the best practices that are an integral part of agile. If they were important in a team in a single location, they are doubly important in a distributed team and have even more impact on project outcomes. Does a distributed team model immediately burden a project with additional overhead? Well, we will discuss this aspect more in the last article in this series, but the simple answer is no. If you have been using best practices for agile-scrum projects religiously – a project with distributed teams just requires a little more focus and diligence. If you were not as judicious as you should be about your practices, then yes, there will be overhead because your risk of failure will be much higher for distributed teams until you get your practices in line.
In our last article in this series, we will explore common myths that crop up whenever anyone proposes any level of distributed teams in software development. Remember, as a nearshore software development provider, these are objections we discuss with potential clients regularly. So join us – won’t you?
If you jumped into the middle of this series, you can go back to the start here.
Agile Methodology, Customer Experience, Nearshore, Product Development, Project Management
Organizational and Team Best Practices
While it might seem that adopting the agile-scrum framework to distributed teams is all about the right tools (especially if you read marketing materials from tool makers), in general, it is more about how you organize your teams and processes than anything else. For that reason, we decided to break this part of the discussion into two sections. Our assumption is you are only going to read so much during your breaks between meetings, on your smartphone….
Project Initiation
There are all sorts of reasons that a «kick-off» meeting is critical for project success, in fact, we’ve already talked about a few in the earlier posts from this series. But in this part of the series, we’re focusing on the organizational elements of a successful agile-scrum software development team.
One of the areas that are especially important is the cohesion and understanding between the individual members of the team. If it is not taken care of the upfront, it can take a long time to build. If you are not aware of the teaming model developed by Bruce Tuckman, this is a good time to start considering it. In short, Mr. Tuckman found that teams follow a regular pattern of «storming, norming and performing» during their lifecycle. If you can shorten this cycle and get too strong performance sooner, you are better off. We have found that kickoffs that include games, team-building, and participative events go a long way to achieving this goal. In fact, for longer projects, planning similar events around specific milestones prevents teams from going back through the cycle later in the process.
There are many guides available for these activities, but regardless of which ones you find useful, the actual activities are not something you can simply jump into and do from a book. It takes practice and experience to successfully integrate team activities into project initiation so the sooner you start using them the better. We have found teaming model to be an excellent resource, but again, it requires some hands-on experience to use successfully.
What do you need to do to assure success for project initiation meetings?
- Include as many team members as possible in a single location, even if some must travel greater distances. The time and expense will pay off handsomely in the end.
- If some team members or teams cannot attend, arrange parallel events that the teams can report on or share in an online conference format (voice, video, photos, etc.).
- Sync your agile – scrum processes, artifacts, and ceremonies across teams and participants with actual sessions during the joint event. Execute sprints if possible (use Sprint 0 as a base). Set expectations with everyone that the processes will be standardized and adhered to across the entire team.
- Establish a shared product vision with presentations, question/answer sessions, product games, etc.
- Agree on core project hours for the entire team (including product owners, proxies, etc.) and communication standards. Core hours should overlap considering the time zones involved. Ensure everyone commits to core hours and provides proxies if they cannot be reached.
- Agree to set regular meetings during core hours even if not everyone expects to be in the meetings. This assures if questions come up during the meetings, they can be quickly answered.
- Agree on timing for sprint planning, retrospectives, and other planning activities. The more standardized the timing for these meetings, the more likely they will be to be integrated into individual routines.
- Learn and respect cultural viewpoints across the team, festivals, language preferences. Plan to share status around holidays, common activities, etc.
- Encourage an atmosphere of fun, respect, and collaboration.
This is a lot to accomplish in any timeframe, much less a day or a few hours. Project kickoffs must be carefully planned and managed. They could and often should take more than a day. We’ve had initial meetings, including initial work, take as long as a week. Once you have dealt with them to and from aspects of the travel, the rest is relatively inexpensive – so don’t push to shorten the time more than necessary.
Best Practices for All Scenarios
Planning component breakdown during the kickoff.
We’ve said that part of making agile-scrum for distributed teams successful is including many of the necessary best practices in all projects, not just the ones with distributed members. These best practices are critical for distributed teams, but also just good practice in any software development project. Your distributed teams will «catch on» quicker if these are part of your regular practice and adapt to new situations better.
- Participation by every individual in the team in meetings is always important. That said, it isn’t natural for everyone. Team members must be positively coached to engage in active, personal participation. Avoiding situations where one person becomes the de facto spokesman for the team helps to ensure team members don’t sit back and not contribute. Trust is an important element in participation. Team members must feel comfortable questioning ideas and playing devil’s advocate when necessary to draw out concepts and beliefs. Each team member must feel enabled to speak directly with the client/project team to avoid forming communication chains that will inevitably muddle and shorten their message.
- Plan frequent live demos and retrospectives with time for questions and clarifications. Communication in these meetings should not be more tightly time-bound than necessary, but when long conversations do surface, don’t be shy about moving them to a parking lot to be addressed in a specific meeting meant to resolve that issue with the right people involved.
- Scrum masters should be careful to practice servant-leadership roles. They need to concentrate on removing impediments so tasks can move forward rather than prescribing how tasks should be done.
- Pre-plan a larger window of future sprints on a weekly basis (depends on the length of sprints) specifically to expose interdependencies between teams, roles, etc. and groom backlogs with the team as a whole.
- Lean to short sprints rather than long and synchronize/prioritize between teams regularly. Avoid situations where a team could go too far down a path before syncing with others.
- Have irregular, casual «brown-bag» sessions to discuss technical alignment, decisions and common ground among members and teams.
- Find ways to rotate team members. Rotation can be between locations, roles, among teams, etc. Don’t allow individuals to become insular units by themselves or with specific team members. Accomplishing this goal can be challenging, but it is especially important in longer projects. Rotation should not be «one way» (always to the client site for instance) and where it isn’t possible, consider remote pairing too as an alternative.
Granted, these points are not easy to accomplish. They take planning and practice to get right – but the aim is to ensure a successful project and enough cannot be said about how much of success is preparation. The next installment in this series will continue to explore organizational and team issues, there is a lot to cover. We will also cover issues related to specific scenarios that we have found take a slightly different approach. I hope you will stay with us to see how important it is to understand software development projects in an agile-scrum environment and learn more about what is needed to extend it to distributed teams.
If you are coming in the middle and want to jump back to the start of the series, you can start here. Or if you are looking for a software development partner and want to contact us, just click here and leave us a message and we will be contacting you ASAP.
Agile Methodology, Featured, Product Development, Project Management
When you develop software products in a repeatable, production fashion, you have to step back occasionally and take the long view so you can properly discuss the process with clients. We’ve been involved in that exercise recently and I thought it might be useful to share the what and why of our approach to software product development for online products.
First, there is one basic idea that informs all of this:
We define the “Big Bang” Market Release model as:
- A black-box project where significant work is done up front to bring together requirements documents which detail the features and functionality in great depth for a software development project that typically lasts from 12 months to two years.
- The time expended on requirements development is expected to provide prospective developers with a very specific vision of the product that can be put out for bid, will put a box around scope, cost and time, and will last throughout the project.
- On release, the exhaustive feature list is expected to drive market adoption and leapfrog existing competitors.
This is different from the closed box, rapid development method that is sometimes also called «Big Bang.» In that in that case, no time is expended on specifications or plans with users or clients. In Big Bang Development, the development team comes up with all the features and implementation based on a rudimentary concept, goes away, and hopefully comes back with something useful. To say we are not believers in this software development methodology is something of an understatement. It is high risk and low reward because the client does not fully understand what they want or what they will get.
In contrast, the concept of the Big Bang Market Release comes from the simple idea that a product can create a market simply by existing in a complete vision that will bring out buyers for a concept that may have never existed before. Specifying software product development in this situation is tricky. Apple has been the leading success story that is cited when this concept is brought forward. Companies that want to create markets, but cannot do the entire product development in house, strongly understand their need to reduce the risk of failure to realize their vision when the application is ready for release. And often, because of the technology and innovation involved, they know they cannot provide the in-depth technical oversight needed during the project. So rather than allow interpretation or adaptation during development, extreme care is exercised to write very specific requirements and lock them down.
Regardless of those worthy aims, these projects continue to fail because:
- Controlling scope over the life of a project becomes increasingly difficult as the project complexity and time span increase. Prediction accuracy degrades geometrically over time – eventually yielding a project plan that can only be relied on at a high level.
- Technology continues to respond to Moore’s Law. The longer the requirement development takes, the longer the project goes on, the less likely it is to meet the expectations of the market on delivery. User expectations have moved on, informed by alternatives they have tried in the interim. In addition, the technology assumptions at the beginning of a long, complex project don’t always work out when development actually takes on the complexity of feature integration. So the choice of a tool, framework, or library may seem like it solves a lot of problems at first, but in practice may turn out to be a black hole into which resource time disappears.
- No matter how detailed requirements are – they are limited by two things: point of view (the classic story of the blind men and the elephant is the common point of reference) and actual feedback from end users of the resulting application. No matter how carefully feedback from end users is brought together for requirements, it is only as good as their vision of the final product. As we and others have said many times – if you asked people at the start of the 1900′s what they wanted for personal transportation – the requirements would only lead to better horses. It is rare for requirements to both anticipate user needs correctly and the complexity of delivering them in a particular way. The risk in requirements actually increases the more detailed they become – especially in cases where they are so specific they cannot respond to end-user feedback early in the development process.
So – what is the alternative?
Consider “Lean Product Development» as a base. We have developed an adaption of the lean concept to software product development that we have leveraged over several projects and across several industries :
Lean Software Product Development
The phases and their aims break down this way:
- Sprint 0 – During this phase, requirements are verified, technology choices are made in detail (architecture, stack), user stories are built (we use agile development techniques – user stories are roughly equivalent to use cases), and the user experience (more than just interface, how a user will use the product) approach is developed to set interaction standards. The outcome of this phase is a set of technical specifications, personalities (roles to a degree), and prioritized user stories with effort estimates for each story.
- Alpha Version – During this phase, the underlying framework is built and core functionality is developed for key end-users. The point of this phase is to verify the product vision with the key audience of the application – the end users who perform the most critical tasks and use the application most. This means the alpha version needs to be actually be tried by the core end-users. This usually requires client partners – which in the case of a new vendor requires getting out into the market and bringing in some early adopters. The outcome is to lower risk. The cost at this point is low, compared to the whole project, so changes can still be absorbed without loss of large portions of developed code and sunk costs. Also, at this point, the approach of the development team in carrying out the vision of their client can be verified early – so that adjustments can be made and trust between the client and the development team can grow. This approach follows the sage advice articulated by Steve Blank – the point of early user validation is to get «out of the building» and get in front your audience early so they can inform development before costly mistakes are made.
- Beta Version – This phase produces the first cut of the market version of a product. It is important to understand that the scope of this version is intentionally limited to just what is necessary to deliver value to end users. In other words – deliver just what they will use and PAY FOR. This is a critical assessment that is informed by both the vision of the subject experts and the feedback from the Alpha Version. The problem is, however, no matter how good the vision and feedback are, there will be additional feedback when the product hits the many different contexts of actual target end-users in the market. The release of the beta version also provides the “kick-off” of internal operations for the provider – and in the case of most products – support, sales, and marketing. The lessons learned from beta release then inform the next phase so that beta adopters are rewarded (and retained) and operations deliver the message and services needed to drive new customers and user adoption. Because of the incremental nature of agile-based release cycles, the actual point when sales are made during this phase varies a lot between products – but development doesn’t stop. What changes is that development is now more directly informed as new customers come on and participate in the beta. Some companies test pricing and marketing more aggressively at this point than others – but the general recommendation is to establish pricing early and test it against the perceived value from users. The outcome isn’t expected to be an adjustment to pricing directly but rather an adjustment of features or packaging to better align with perceived value.
- Market Release – This phase marks the release of the full market product and the beginning of “normal” product enhancements to continue to grow functionality in alignment with user feedback. We sometimes add a phase for development up to market release itself that is separate from beta – but for general purposes – development has now slipped into an enhancement mode, rather than full out development unless there is a significant difference from what is planned for release to beta customers and the general market. The outcome of this phase is a product informed by target user feedback, tested business operations and a change of focus from getting the product “out the door” to getting customers and continuing to enhance features and functionality. It is not an end point – it is just the start of the natural evolution and “pull” of a “consumerized” online product.
The outcomes of this process are:
- Early release and feedback from the people who count – the actual paying users in the field.
- Early validation that both the vision and the requirements are resulting in a product that delivers value and will meet market expectations.
- Lower up front risk and lower time to profit. Waiting over a year to put a product in the market with real users is a recipe for disaster. Getting into the market, proving operational assumptions and kick-starting cash flow as soon as practical is key to success. The sooner you get into the market, the more time you have to adjust to reality before your startup cash pile is burned up.
- Simple – a higher chance of success measured by what counts – adoption, cash flow from customers and retention of users.
However, some of our customers face a little more difficult situation – they have an existing product in the field that started life as a traditional premise-based product and is now being pulled to adopt a more dynamic, online model. That brings an additional set of issues:
- If the development cycle is long, existing clients may jump ship before the full online version is available.
Support and maintenance of the existing product can overwhelm the key members of the product team that need to be available to shape the new product. Finding a point when transition can begin in an orderly fashion, without cannibalizing existing sales is critical.
- The new direction provides an opportunity to develop new markets, adopt new pricing levels and transition to a pull-driven feature model (rather than the push of traditional product releases) but timing is key. For a complex product meeting the needs of the top of a vertical market this becomes a huge exercise and is frankly very difficult to break down into manageable pieces.
To deal with that we have a general model that takes the new product template above and turns it into a phased development of a suite of products. In the diagram below – you can think of each of the blue boxes as a modified run of the our typical product develop cycle:
Progressive development for a suite of online software products
The major steps in this are:
- Sprint 0 – A holistic project-level requirements, technical specifications and feature breakdown that sets the stage for the entire project – but doesn’t lock assumptions down. The point of this entire project is as before, get products out early, get feedback and cash flow as soon as practical. This also includes a more detailed look at the first product in the suite.
- Web Enhancements – This part of the first product release is optional, but worth considering as a way to ensure existing customers stay onboard for the long run and can see the long vision early – so they will become key in feedback as the product progresses through the lifecycle. What form this product takes varies, but the idea is to enhance the existing product with features that suit the Internet environment particularly well and extend it in ways not possible before because of technology or restrictions inherent in the on-premise version.
- Broad Market Version – To allow early feedback and to get into the market as soon as possible, the first product needs to be a focused subset of the expertise expressed in the legacy product that addressed the top of the market previously. Generally, this means providing a set of features that will provide value for the 2nd and perhaps 3rd tier of the market. Again, all the points of a typical product release as we first described need to happen in this release so the product is informed by actual end-users in the target market – which coincidentally is a new market for the vendor.
- Professional Version – Building on the same code base as the Broad Market Version, the professional version targets the features which will satisfy 70-80% of their installed base. This sets the stage for migration and broadens potential adoption by a group of customers who will pay significantly more for the value the product delivers. This also marks the point where legacy support and maintenance can begin to turn the corner and clearly move toward the new product.
- Enterprise Version – Again, on the same code base, enterprise functionality is added and now the entire “product suite” has reached levels of functionality never achieved in the legacy version. Users pick levels by feature packages within the suite – so if properly architected – there is a lot of variation in pricing and packaging possible to meet needs in different markets.
It should be said that the timeframes proposed here are generalizations and will vary, but – they are based on the assumption that development should focus on delivering features with value to end users. Everywhere else, the simple rule “less is more” should be followed with the leverage of services and frameworks wherever practical. The architecture needs to allow those services to be used as long as necessary, but to be replaced as growth provides the option to drive down the cost of service. It should also be said that features and customization in this approach come from choices of what is made available to roles in market packages and configuration – not separate versions.
Now, I’ll admit this is a big vision and a lot to absorb in any context – either as a startup or a software company with legacy products in the market. And – it is a big shift in how we have looked at software product development. It comes from our own experience of the issues we find repeatedly in the market. I can’t say it is an approach that every development group can provide successfully. It depends on making clear choices that will provide these outcomes and not waffling with half measures.
What do you think? Can you see your company going down this road? Can you see the benefits? Let me know…
Do you want to develop a lean software product? Contact us right now!
