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!
Customer Experience, Featured, Outsourced Engineering Team, Product Development, Project Management
Background
Before we discuss this subject – let’s reach a common understanding of what we mean by Soft Skills for Software Development Teams. Developing custom software requires a clear understanding of what the client needs to accomplish with the finished product. If you work in application development, you are aware that often this is a subject the client is not fully settled on when development begins, even if they have planned extensively. In fact, if the client believes they have all the bases covered in their application requirements, it is wise to be very careful and ensure they have the ability to be flexible at both a product and contract level. We all know that things will change as the product is realized and new opportunities present themselves. We also know that unexpected issues will come up during the project and the longer and more complex the project – the higher the risk will be. What we don’t know is how much change the project will need to be successful as envisioned and if that will be acceptable to the client. Realizing a product successfully requires that everyone on the development team is able to see more than the task that is in front of them and is enabled, personally and professionally, to help shape the outcomes. Without that, they are just following specifications in detail, not contributing their experience and insight fully and that can mean that things will go off the rails before anyone can pull them back. For developers to effectively provide the insight and experience they have to the project – they need to be able to use a range of soft skills.
On the other hand, no one can expect all or even some software developers to be business consultants, but in most cases, the same skills we expect our business consultants to have, can make all the difference when they are applied to the project from within the development team.
At a high level – what are these skills? Communication, negotiation, problem solving (creativity), and strategic thinking, but – within the context of the development team and its role in the project. There is a larger, more specific view of soft skills, but we will get to that later.
Scio Development Center, Morelia, Mexico
The team context is critical. If the development team cannot come together to support a concept or conclusion that could be advantageous to the project, it has a near zero chance of moving forward, no matter how valuable it may be. This doesn’t discount the visionary individual who sees the opportunity for change, it simply means that before the idea can move forward – the individual needs to exercise their soft skills to bring their team on board as a first step. And if the team does not feel enabled to exercise their creativity and insight, their soft skills for the concept, it will never happen.
Another common misconception is that roles like Project Manager and operations like communication are in themselves soft skills. Both areas benefit from soft skills greatly, but being a good project manager has more to do with how the role is defined than anything else. In larger teams, where the project manager is more of an administrator and deliverable coordinator, more of the work is defined by procedures, checklists, and project plan maintenance than soft skills, although certainly if the plans go wrong, negotiation becomes key. In these larger scenarios, communication also becomes bound up in processes and notification cycles that are often automated, if not run by assistants and procedures. In smaller agile teams, like we use at Scio for agile software development, soft skills are always important because there are fewer intermediaries and roles between the client and the development team. In general, while procedures certainly exist, they are more flexible and can be changed to fit the context of the project quickly. In these situations, there is little to no buffer between the development team and the key stakeholders on the client team. The better the members of the team are at leveraging soft skills, the better off the whole project will be. Smaller teams have to be creative, able to communicate their ideas and support them with analysis and strategy, and finally negotiate a path to a better outcome.
Is there a process under it all?
There is a process that ties together all soft skills that – when it is done right – makes all the difference. It is the process a team or individual uses to arrive at a conclusion for presentation, negotiation, and hopefully, acceptance. It is basically the same system a business analyst uses to present findings, but it needs to rely more on arriving at the conclusion as something everyone in the team can agree to and support. I bring this up because although all soft skills can be used by themselves, it is easier to see the value if you put them in the context of developing a proposal for a change in a project.
Considering the steps
- Gather Information
- Open, contextual questions delivered with empathy. As you gather information, conversations and the questions in them need to be developed within the context of the organization and with an understanding (empathy) for the people you are talking to. The communication soft skill of developing questions to gather information and delivering them with empathy has considerable value and too often ignored. Not using it properly results in few useful answers («yes» and «no» answers don’t give you any context) and little understanding of underlying drivers.
- Research – Of course, the skill of analyzing sources is critical, but so is using the team and peers as resources in research. They will bring different points of view and experience that can be expose additional lines of discussion.
- Analyze
- Document Scenario – Analysis must be based on the scenario under consideration and it must be documented clearly and agreed on by the team.
- Record Analysis – The analysis, under the scenario, needs to be referenced to the research and interviews
- Team Inclusion – Again, the team and any peers consulted need to be pulled into the analysis through review and discussion to ensure they understand what was considered before the conclusions were reached
- Develop Conclusions
- Attach to research and analysis – by the time you reach the conclusions, you should be able to draw clear lines between the research, the analysis and the proposed conclusion. Referencing back to those areas is key to achieving a collaborative conclusion.
- Team Inclusion – Of course, if the team is going to support the proposal, they have to understand the conclusions and how they were reached.
- Reassess
- Record Current Context – Document the current scenario and how it has changed.
- Cycle Back through the steps and document, changing as needed and adding new conclusions.
The process of developing proposals will use all the general skills above and if we get more granular, some more as well. Ultimately, they are the skills teams need to be successful and clients need to make decisions and gain confidence in their development team. But, the development team should not wait until the problem that needs to be solved is so big that it takes days and reams of paper to present. At that point, it is too late for the team to intervene because of project timelines and pressures. If problems are recognized early and conclusions are well-documented, they should be able to be presented in a short PowerPoint presentation. That is a much more realistic target for a development team if they can leverage their soft skills effectively.
A more comprehensive list of soft skills for Software Development Teams?
We’re not going to go into detail with the list we use of soft skills for our team training – but it is a good look at what we find useful to bring development team members to a level that improves their ability to add value to a project from their experience and insight:
–Thought Skills
- Associative Thinking (Connect the Dots)
- Analytical Participation
- Effective Questioning & Participation
–Team Skills
- Cultural Integration
- Collaboration & Coordination
- Key Stakeholder(s) Identification, expectations, Concerns
- Teamwork & Success (also a personal skill)
–Personal Skills
- Time Management (also a team skill)
- Always Learning, Improving
- Self-Confidence, Interpersonal Skills
These areas, laid against the normal team analysis, project management and delivery skills required for software development, bring a better experience for clients and higher job satisfaction for our team members. But with that understanding of the «why» behind a focus on soft skill development, the biggest barriers must also be understood:
- Soft skills do not come easily, especially in the areas of communication, collaboration and negotiation. Everyone must practice, fail, reassess, and continue the cycle to improve self-confidence and the interpersonal skills that are so important.
- Soft skills take time to develop and in the end, have to come from hands-on experience. One class, one try, does not suffice for training. The ball needs to be passed around so that everyone can get time to gain the confidence necessary. It is like driving a car – you cannot watch a series of videos on Youtube and expect to drive a car properly. You need to get into an actual car and feel what happens as you are moving along to learn and grow.
How can you get value out of soft skills?
As a software developer, can you remember situations where you saw a solution to a problem that you couldn’t properly communicate to your team or client? If you have any experience, you have. Taking some time to research, experiment, make mistakes, ask someone to mentor you in soft skills, can make all the difference. If you have mastered some soft skills, mentor others by doing – don’t wait for them to ask.
As a client, look for ways to support your team and enable them to leverage their soft skills. There is no question we are all made smarter by working together and it lowers the burden on you and your team. You can’t expect all ideas from y0ur development team to be acceptable – but the richness possible from an inclusive, collaborative environment can increase your chances of success and decrease your risk considerably.
As we move forward to achieve better outcomes and a more positive customer experience – custom software development must continue to look for opportunities to lower risk and achieve better outcomes. Development teams can act more as partners in product development and success and less as commodity labor. It is a vision we need to continue to work on – and realize – one person, one team, one project at a time.
