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, Project Management
Our thoughts on this subject come from practical experience. Companies who come to Scio with their projects often come with a multi-megabyte PDF, UML diagrams, and a list of specifications. “Give us a firm, fixed price for getting this project done by June 2nd at 2pm Eastern,” they say.
Their basic idea is:
- Software projects have a much less than enviable record of finishing over budget and way over the estimated completion date – we’ll set those so they can’t creep.
- Software outsourcing is risky so we’ll limit our risk by agreeing to a cost and timeframe we can live with and possibly tag onto some event. “Shoot for the June trade show so we have a shiny new product to sell,” Marketing begs.
- We don’t have the resources to do the project in house, but we don’t trust any outsourcing group – so we’ll rope them in with a fixed fee and time and put all the risk on them.
- We know perfectly well what our product needs to be. If we don’t nail this down, we won’t get what we need for the price we can afford.
The result of this thinking generally speaking is:
Flaming Disaster!
Why? Their basic instinct wasn’t wrong. Software projects do fail to meet their targets with astonishing regularity. They were just trying to limit their exposure. What is happening?
There are five intrinsically linked factors in estimating software product development projects:
- The Total Elapsed Time expected to produce the specified product.
- The Effort required to produce the product.
- The Cost the client expects to expend.
- The Resources required for the project – their skills and availability.
- The Specifications for the product; the features, functionality and user experience.
In general terms, what clients are trying to do is set a “target.” In project management, the general assumption is you can set any one of the five factors as a target for a project, but when you do, you need to let the other four float to where they need to go to reach the target. So if you set cost, you need to vary time, specifications, effort and/or resources to reach a mix that will achieve the project goals within the target cost.
Instead, clients set two or more factors in an attempt to “hold the line” on all the other factors. They spent a lot of time on those specifications. They need them all!
But in fact, setting more than one factor as fixed creates an almost impossible tension among the remaining factors that almost assures the project will fail to meet its goals. There are no levers left to control the project! It starts out with the best of intentions, but with two or more factors fixed, any change in circumstances during the project creates an imbalance that cannot be corrected with the remaining factors.
Why does this happen? Stepping away from our example of setting time and cost as the fixed factors – think about each of the factors individually and the impact they have on the project:
Time
The elapsed project time from start to finish is always different than the total effort applied. Time is measured by a calendar start to finish. Conversely, the effort is the sum of all the time expended on a project by the assigned resources. Total time is never equal to the total effort unless only one resource is assigned, full time.
Software development projects rarely finish on time. Unplanned specification changes, unexpected risks, and resource changes always build up over time and eventually result in a project that is both over budget and beyond the allocated time.
Time to completion can only be estimated and controlled well over short periods. As the time period considered in an estimate increases, the accuracy begins to degrade because of variations in the expected effort, the depth and complexity of the specifications involved, the skills and availability of the resources required and the limitations an assumed total cost puts on the project.
It should also be understood that time to project completion is rarely scoped as a direct result of estimating the effort required. More often, “artificial completion dates” evolve from a point in a product marketing plan, the current product position, and/or customer demands. When this happens, there is usually some consideration of project scope but is rarely enough to address the situation that arises from not first doing a straight-forward evaluation of the effort required to complete the specified product.
Effort
Scio Consulting
The accurate estimation of effort is key to successful software project costing and setting a realistic expected time to completion. In practice however, the amount of effort required to actually produce each bit of application functionality always varies from estimates. The more detailed and contingency bound the estimate becomes, the more likely it is to be wrong. Because of this, past experience and general effort assumptions are used across a project estimation, in the belief that in the final outcome everything will average out. Of course, the reverse is also true; averages can never address all risks in an individual project. So, while averages are a practical approach to project estimation, they cannot yield a project quote that can be fixed to a specific figure without risk.
In this situation, risk buffers for variations in specifications and resources are recommended for effort estimation, especially in Agile development methodologies where development iterations are “timeboxed.” Timeboxing iterations means variations in the effort will generally cause functionality to be pushed ahead to the next iteration and a “snowball effect” can be produced where the amount of effort required for each iteration increases incrementally beyond estimates over time. If buffers were used, more projects would reach their estimates, but in the drive to reach a more competitive price, they are rarely employed when using assumed effort to arrive at a fixed cost. This results in a very narrow margin for error in effort estimation.
In addition, the amount of time required to reach project completion is not directly related to the number of resources available concurrently. Determining effort depends on an experienced assessment of an efficient team size for the project and the methodologies used. Increasing the number of resources and concurrent tasks beyond a certain point increases coordination and communication overhead exponentially. Increased team size tends to increase errors, oversight, and testing cycles without a cost-effective increase in total output.
Estimates of effort required tend to be assessed from a straightforward analysis of specifications. During projects, the actual effort required frequently increases beyond estimates because of “fixes” required to bridge the gap between specifications and the product as realized in development. In addition, the elapsed time required for QA by the client team is often underestimated and can result in either idling development or moving ahead with incorrect assumptions and subsequent rework.
Cost
Software development projects almost never finish under their expected cost from the point of view of clients. A few finishes at the client’s target cost, but generally only at the expense of other project factors. As a result, when projects do cost what was originally expected, the product is often a failure from an end-user point of view.
For clients, the target project cost is generally a function of:
- Expected product price and the desired return on investment that could be produced by an estimated number of paying customers in a reasonable period of time. In other words, a string of dependencies that may have little basis in the final analysis.
- Available funds and cash flow limitations.
- Experience with “similar projects” – However, only rarely do estimates based this way actually works out to be similar in the effort required.
Target cost is never or only rarely based on:
- The steps and effort actually required scope and develop a product that is a successful market fit.
- Small, incremental steps that can be estimated with a reasonable chance of success.
Specifications
Specifications are almost always assumed to be a known and set factor in fixed cost projects. They are used as the basis for effort estimation and effort estimation ultimately determines the quoted cost. Clients generally have a basic expectation that their specifications do not need to be varied from substantially to produce the desired product at the specified cost. Clients often expend great amounts of time producing specifications for bid to assure they will be complete and assumed to be fixed. But in fact, not assuming specifications will need to be varied as over the course of a project to meet fixed cost results in a continuous tension between the effort required, the scope remaining and the time remaining on the project clock.
Most fixed cost projects have intentionally limited options to change scope. Instead, limiting scope change by not providing workable options increases the risk the project will not reach the desired goals when the actual product is assessed by end-users.
Software development requirements can never be complete enough or communicated well enough to ensure understanding and success. Errors in interpretation, over-broad and over-complex specifications result in many “fixes” that are not related to actual code errors by the development team. These fixes are actually elaborations or “clarifications” of project specifications, but in most projects, they are assumed to be “bug fixes” in the process of development, testing and QA. In practice, this means the actual functionality works as specified but the implementation is not as desired by the client. Fixes of this type generally add to effort and resource allocations without the assumption they should impact specifications, time or cost.
Software development project requirements are by their nature improved by the discovery on the part of both the development team and the client team during analysis and development.
In the course of normal work, discovery exposes:
- More depth than expected (scope creep).
- Different aims and approaches from the client and end-user feedback or unexpected insight from seeing the product as it develops.
- Technical limitations or alternative approaches that change requirements, the effort and time required.
- In most software development projects, there are no assumptions or procedures to handle specification discovery and subsequent changes. This results in many variations from project estimates and is a significant factor in project overruns.
Resources
Resource management is a function of having the right skills available when needed for a specific task in a project. With limited resources and funds, this is a difficult task for software development companies.
Both internally and externally, software development companies have an ongoing need to balance new projects against support, maintenance, and enhancement of existing applications. Companies need to decide the level of investment they will put into new technology. Using time from existing work to move to new technology skills is a difficult and expensive proposition. Recruiting for internal resources is a long, expensive process that often fails to yield dependable, trained resources in the long run.
These factors are the leading reasons clients consider outsourcing. But they are also a factor in outsourced projects themselves because, at some level, the client team becomes involved directly with the outsourced team and the results of team resource management. The management of new software development projects is difficult by itself. Because of the time and risks involved in recruiting resources with appropriate skills and knowledge, client project/product managers often don’t have a good understanding of the technology and limitations in the project they are managing.
In this situation, outsourcing software development often leads to a confrontational relationship where the client team feels they have lost control and don’t understand the choices the outsourced development team has made or what effort is being applied to produce deliverables. They don’t understand that the estimation for time to completion was figured against assumed effort but the accuracy of that assumption varies according to specification clarity, resource skills, and availability.
In Summary
Variations in the five factors during a software development project leads to:
- Defensive reactions to clarifications and changes between the client and the development team.
- Situations, where the actual effort in the given time varied depending on specification accuracy and resource skills and availability, lead to confrontations. When the time to completion is figured for a fixed cost, it is generally figured against the assumed effort. Without assumptions for what controls are available to deal with variation, the confrontation continues to simmer throughout the life of the project.
- Lost opportunities for a partnership-like relationship of shared risk and reward.
The solution could be as simple as not setting more than one factor as fixed, but in practice that is hard to do for many projects. What is really needed is a consultive framework for communication and decision making that is informed by real-time reporting during the project and the collaborative resolution of issues to reach the client’s goals. It’s easy to say, but it takes understanding, planning, and agreement to accomplish.
We’re constantly working on this paradigm every day – it’s challenging and rewarding. What’s your experience? How do you hold the line? What controls do you have realistically? Have you recognized the five factors in your project estimation process formally? I’d love to hear your thoughts…
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!
Agile Methodology, Customer Experience, Mobile, Nearshore, Outsourced Engineering Team, Product Development, Technologies
When building any kind of company, there are steps you must take that will do the most to ensure your success. These steps are especially lucrative when building a company that works for other companies such as the ever-growing industry of software-as-a-service. It may be difficult to know on your own what are some of the ways you can ensure success in your software service company. To make it simpler for you, we have compiled a couple of the ways that you can see to it that your company has the best shot of success.
Keep it simple
Because software is often self-serve it is best to keep it simple and easy to use considering the majority of business owners aren’t computer geniuses. Making it more user-friendly will mean that more people will want to use your software for their business. Keep it simple, tidy, and user-friendly.
Never stop improving
O
ne way that a lot of software service companies fail is that they become complacent with their software. A good software service company listens to their customers and continuously improves and updates its product to make it work even better and smoother. Monitoring what the consumer is saying allows the software service company to cut out unnecessary functionality which ties into the “Keep it simple” rule.
Offer several different packages
You should always have more than one package available where the first and lowest functioning one is basically free. From there you can increase the price per software based on customer needs, usability, willingness to pay, and ROI.
Display a path to profitability
Oftentimes a company will not be profitable simply because they invest their resources to sustain growth. Good service software companies must show that they plan to be profitable in the next few years and that they have a path to profitability. The best way for a company to achieve this is to hit profitability every couple of years before reinvesting.
Offer the perfect mix of services
Offering the right amount of services can be difficult for a company but it is highly lucrative to the success of a said company. On one hand, they increase revenue and reduce churn rates whereas on the other hand they reduce margin and increase deployment time and cost of sales.
Commit to the success of your customer
One of the most important things to remember when growing a software service company is to sign new customers as well as commit to grow and secure its recurring revenue from previously signed customers. To accomplish this, the company must be monitoring its customer’s usage levels continuously as well as send them customer satisfaction surveys and product updates among other things.
These are just a few of the major points to remember when you are trying to build a successful and profitable software service company. Along with these, you will find that you discover things that work for your company and your specific product and what does not.
Are you ready to develop your App?
Click here and schedule a meeting
Scio provides end-to-end engineering services in a collaborative partnership to ensure that your team is an integral part of the solutions you require. We can offer a wide range of skills to make up a team that you can depend on – and work with directly. And when you need something more – we’re flexible. From helping to assess your needs to developing, implementing and maintaining solutions, we can offer as much or as little help as you need. Our teams can work with you virtually or on your site – but most companies need some type of combination of the two and we’re more than happy to find that blend too. If you think that sounds interesting – Contact Us. We’re ready.
Agile Methodology, Nearshore, Outsourced Engineering Team
Software development projects use different types of software development life cycle (SDLC) methodologies, depending on their nature and requirements. They basically define the way that software development work is organized.
The two main approaches are the traditional or waterfall method and the agile software development method. How are they different from each other and which one should you choose for your project?
First, we want to define each methodology:
According to Wikipedia «the traditional methodology or waterfall is a sequential development approach, in which development is seen as flowing steadily downwards through several phases»
On the other hand, Agile methodology is defined as a way of building software through incremental, iterative work cadences, known as sprints. «The highest priority is to satisfy the customer through early and continuous delivery of valuable software» – Agile Manifesto
Comparison between Agile and Traditional Software Development Methodologies
-
Software Development Lifecycles
One main difference between the traditional and agile methodologies is the sequence of the phases in which the software development project is completed.
The traditional method uses a linear approach where the stages of the software development process must be completed in sequential order. This means that a stage must be completed before the next one begins. These stages usually comprise the following:
- Requirements gathering and documentation
- System design
- Code and unit testing
- System testing
- User acceptance testing
- Bug fixes
- Product delivery
On the other hand, the agile methodology uses an iterative and team-based approach. Its main objective is to quickly deliver the application with complete and functional components. Instead of completing the software development tasks in sequence, they are completed in sprints that run from around 1 to 4 weeks and where a list of deliverables is completed in each sprint. The tasks that do not get completed within the sprint are then reprioritized and included in future sprints. This also means that the different stages of the software development life cycle can be revisited as needed.
The agile software development method uses an iterative and team-based approach
The typical agile development lifecycle involves the following phases:
- Requirements
- Plan
- Design
- Develop
- Release
- Track and Monitor
With the traditional method, the details of the entire project have been visualized and defined before the project starts. In contrast, the agile methodology allows for more flexibility in that changes can more easily be made even after the project starts.
It is best employed if the scope of the project cannot be clearly defined in advance. This also means that making unplanned software development changes with the traditional method is costlier than with agile.
Customers are highly involved in the early stages of the software development process when employing the traditional methodology. More specifically, their input is needed during the requirements gathering phase, as they must provide a detailed description of what their requirements are with regards to the software application to be developed and how they envision it to function.
However, they have limited involvement after the software development process starts, aside from attending status meetings, doing reviews, and providing approvals. They usually get to see the product in its entirety after a software development life cycle is completed.
The agile software development method requires more customer involvement
In contrast, the customers are highly involved in every stage when employing the agile development process. They can review the application at every phase and make suggestions for improvement.
As a result, the customers are more engaged in the entire software development process, in turn ensuring that they are satisfied with the finished product.
The traditional method has more formal documentation and review process than the agile approach. Each phase of the development process is properly documented and reviewed when using the traditional approach.
On the other hand, due to the quick delivery time required with the agile method, changes are usually made directly on the code, with the developers just adding comments and annotations. This doesn’t mean that documentation is not an important part of agile software development projects.
Documentation in agile is typically seen as a strategic part of the development process, where all that is written has a purpose. It is a simplified document with executable specifications and stable concepts.
Which software development method should you choose?
When choosing the methodology most suitable for your software development project, some of the things you should consider are:
- The speed of completion.
- The size of the system.
- The level of collaboration and interaction that is possible among the software development team members.
In particular, if you need to quickly release a basic product that you can later build on and add more features too, then the agile methodology may be more appropriate for your project. It works best if you have a startup, which means that you have limited resources but need a basic software application to get your business up and running. Likewise, this approach is suitable for small-to-medium-sized software applications.
On the other hand, the traditional method is better suited for projects in large enterprises where the specifications and requirements must be clearly defined before the project commences. Although the project may be divided into smaller components, each of which is developed with the agile approach, this comes with the risk that the individual components may not be compatible with each other once they are integrated to complete the final product.
Finally, the agile software development method requires a high level of collaboration among the stakeholders involved where each stakeholder must be readily available for input or feedback. In this regard, if you’re working with various groups (software developers, vendors, testers, customers, and others) that do not work in a single physical location or that may have limited availability, then the traditional approach may be the better option for you.
Agile vs Traditional
Both traditional and agile software development methods have their own advantages and disadvantages.
However, whenever feasible, the agile approach should be considered, as it provides more benefits, especially for startups. It enables a complete functional software application to be released faster. It is also more cost-effective, as making changes is less costly than with the traditional approach. Budgets can also be determined on a per-sprint rather than a per-project basis.
Moreover, because the customer is highly involved and changes are constantly made to the application, a higher quality of work is achieved.
With the use of technologies such as webcams, VoIP, and others, a high level of interaction is still possible even among remote teams. In this regard, this collaborative nature of agile fosters trusts between the customer and the software development team.
In summary, the software development method most appropriate for your project will depend on factors such as schedule, cost, quality, and the other resources available to the project. As such, it should be the first decision that you and your software development team make.
By organizing the different stages of your project efficiently, you can better ensure its successful completion — that is, a project that is developed on time, within budget, and where the customers are happy.
Want to start building your next software idea? Want to give it a shot on the Agile methodology? Contact us we have been working with this methodology for more than 8 years now. So, let us know how we can be helpful to you. We love to help!
Agile Methodology, Customer Experience, Nearshore, Product Development, Project Management
Technical Best Practices
Building on the discussion of distributed agile-scrum teams in software development we started in the first post in this series, in this post we will discuss some of the principle technical best practices our team at Scio has found to be beneficial for distributed agile teams.
Communications for Distributed Agile Teams
One of the most important areas to consider technically is the use of flexible instant messaging platforms. While these platforms cannot fully replace face-to-face interaction in all cases (especially for first-time encounters), they can go a long way toward building the trust and open relationships that are expected in an agile environment. They must be flexible enough to adapt to a wide range of network speeds and requirements while providing text chat, file transfer, desktop/app share, voice, and video interaction. This requires an understanding of the available bandwidth at each location included in the project, technical constraints of the end user environment, and fallbacks that can be used when the normal application doesn’t function correctly for some reason. Messaging tools must be as «transparent» as possible – not creating extra overhead for ad-hoc meetings that are necessary to iron out important details on the fly, while still providing some extra tools that smooth interaction in larger meetings like side-channel text chats. It may seem trivial to simply adopt one of the many tools available for the purpose, but in practice, finding something that can be widely adopted and quickly brought into daily use is more challenging than you might think. Issues to consider include:
- Messaging security – Some industries (such as health care) and some projects may require security over and above that provided by the messaging application itself.
- Standards – Special situations may require some standards or rules of the road for users and in a lot of cases, enforced rules may be the easiest route to providing compliance for issues like branding, copyright, and industry compliance. This can be especially important when desktop sharing is used – are there areas in users systems that should not be shared for some reason?
- Special needs users – Are there users on the team that require or could benefit from voice to text (rather than keyboard) interaction? Is video easier for some users? It is better to find a platform that provides options for special needs rather than trying to build in workarounds after the fact.
- Availability – There is nothing worse than a messaging system no one takes seriously. If it needs to be tucked away, if it is only used when «planned for,» if there is no response when it is needed to answer a critical question, it is just another bit of project overhead and not a useful communication tool. If everyone does not adopt the same tool – much the same is true. This is really not a technical issue, it is more organizational in nature, but it is a waste of time to implement a special system no one is using. Make it part of the agreements in the project kickoff – and use it.
And one additional tool that is indispensable for communications – a camera. It can be as simple as using a smartphone, but having a way to capture white boards, project artifacts and even selfies of team members can be invaluable to bring everyone to the «same page» quickly and to act as a project memory in future interactions or to bring missing members up to speed. It seems like a small point, but if you only think of photos after the fact – it will be too late.
Project Management, Testing and Source Control
Deciding on the project management tools to be used (or not used) during the initial planning session is critical to success. The actual tool used may depend on the standards adopted by the client team before the project starts or they may depend on the type of project involved. Regardless, they must be network-based (so everyone sees the same project status without forcing updates), agile-scrum aware (backlog, burndown charts, etc.), and easy to adopt without a great deal of unnecessary overhead. Another point to consider – can individuals take responsibility for stories and status transparently? Can they update their status as a part of their regular work? For this reason, we use the Team Foundation Server as an integrated part of our Visual Studio environment as a standard. It has agile templates built in and allows individuals to manage their work as part of their development environment. No jumping out to another application. Of course, that said, we do adapt Trello for shorter projects and smaller teams. The right tool for the job is always important to consider.
Today, testing automation, continuous integration, and standardized configuration management are not just good ideas, they should be standard for every project. That said, access and availability for members of a distributed agile team is an important technical hurdle to solve immediately at the start of the project. Along with rules (more on that in the next article in this series) to push early and often rather than «once in a while» it is a critical element of any team environment – especially for distributed teams. It is not something you can easily back into «when you decide it is needed.» It requires consideration for implementation, training and the processes that will be used. Again, this is a subject to be fully discussed in the project kickoff, regardless of who is implementing and using the systems. A single code repository with logging enforced will go a long way toward understanding clearly where the team is and what is really complete at any stage. Again, this isn’t just a best practice for distributed agile teams – all development teams should be regularly using these tools so there is little to no time required to reach productivity with them.
One more thing? Clocks on the wall, for each part of the distributed team, with labels. It seems simple – but when you need to reach someone before they leave for the day – it can make all the difference.
Wiki?
It might seem trivial, but a networked team wiki with space for sharing assets, current status (including builds, etc.), coming meetings, etc. can make all the difference to both communication and «personalizing» interactions between team members. A project wiki can include:
- Project wiki with procedures, contact lists, learning during development, editable spring plans, project artifacts (photos, documents) both up to date and historical.
- Team member profiles with photos, fun facts, recent changes, etc.
- Photos and notes from casual and social team meetings (games, lunches, etc.)
- Hours, holidays by location, agreed core team core hours and days when all team members will be available.
Each individual project may have additional technical issues that have to be considered, but this is the starting point we use to consider the set up for every project. In the next segment of this series, we will consider the organizational issues involved in adapting the agile-scrum framework to distributed agile teams. Stay tuned!
Did you come to the party late? You can find the first article of this series here
