Prototyping for Pros — How to Rapidly Prototype for Software Development

ux-788002_960_720
Attrecto team

Attrecto team

Prototyping for Pros — How to Rapidly Prototype for Software Development

You usually don’t have to preach the perks of prototyping to designers — they’re in the know. It’s their process, their everyday expectation:

Have project, will prototype, goes their mantra.

But what about software development? 

According to CapGemini, prototyping for software can bring on 4 distinct advantages for teams looking for:

  • Clarity: using “throw-away prototyping” to get requirements right
  • Iterative thinking: using “evolutionary prototyping” to think and build in an iterative and progressive manner
  • Getting the customer involved early on: using “customer value prototyping” to focus on and discover a customer’s needs or expectations of the software solution
  • Concept visualization: using “rapid design and visualization” to communicate and visualize the projects to clients/stakeholders 

Why does this matter? For an app development company looking to stay competitive, there’s a distinct advantage to adopting a user-centric point of view.

Because so many app development teams and companies already operate according to agile methodology, often working in a scrum environment, prototyping can support the need for an ongoing form of customer and user feedback in development.  

Source: The State of Software Development 2018

So what does software prototyping look like? And what does a web development company stand to gain when harnessing rapid prototyping? 

Let’s take a look.

What is a Prototype?

Prototypes are…

“an initial or preliminary version from which other forms are developed. This provides you with insight into the functionality of your design and any changes needed in order to make your work a pleasure to use.” — Daniel Bramhall, “The importance of prototyping your designs

Prototypes can be as simple as sketches, drawings, and drafts, or more physical and complex like models, sculptures, and replicas. 

The idea behind a prototype is two-fold: 

  • To provide a simulation or a sample version that can also act as a convenient starting point
  • To use the incoming observed and measured data to test out the product from this sample and gain new ideas on what’s working and what needs to be improved upon

The whole point of a prototype, then, is to both plan for and precipitate change. 

Software development, as a discipline and as an activity, knows all about change. And this makes prototyping especially useful in the beginning stages of information gathering, requirements, and estimations. 

Source: Unsplash

Download your free guide for development process  in UX driven projects
Download your free guide for development process  in UX driven projects

Prototyping is essential and inevitable

Here, we’re talking about prototyping the code that runs the show and/or the features that will be included.

Within software development, prototyping holds very concrete and distinct advantages. 

  • It can help resolve issues of usability by connecting the user to the software at an earlier stage in agile or iterative development
  • Building out a prototype before can reveal areas that need improvement or features that must be thought through more carefully
  • Real users can interact and use the final version, allowing developers to track whether there is enough simplicity and ease or if the code is too buggy, clunky or inefficient
  • In the beginning, a “rough” or “lo-fi” prototype can help elicit requirement as well as validate requirements your team might have forecasted
  • Prototyped programs can help transmit intent not just for the user but to the development and design team; moving from concept to visual model engages a different level of understanding and creativity
  • It can be seen as an essential risk reduction activity, especially in cases of the accuracy of estimations and the anticipation of the scope change requests down the road

Source: “Prototyping in a scrum environment“, CapGemini, Slideshare

Keep in mind that, besides the types of prototypes you can create, based on stages of development, there are also various modes of detail. 

“Lo-fi” prototypes are much less detailed, high-level, conceptual and simplistic. As a result, these designs are:

  • not entirely definite
  • used when the focus is on scenarios of use and user flows
  • intended to clarify the thinking process without too much clutter

Compare this with “hi-fi” prototypes, which are much more detailed and closer to the end model/concept, as well as:

  • used when you need to convince stakeholders who are looking for an investment from a VC, for example
  • used when the designs are nearly done
  • chosen if you’re only iterating or adjusting for functionality/features

4 ways prototyping helps you go pro

Prototyping, especially within the context of agile methodologies, is a stage by stage process. As we saw previously with the Cone of Uncertainty, the phases of a software project’s evolution, especially in the beginning planning stages, can be shrunk significantly. In lieu of this “quick” and “lean” start, development is spread out throughout the course of its growth, from the first conception to “final” iteration. 

Prototyping is highly conducive to this “iterative” nature as prototypes can be improved upon. Some formats of prototyping, such as wireframes, as we’ll soon see, are more flexible and relevant to the process of prototyping. 

It also helps hammer out four key elements of production and development, including:

  • Interaction: How does the user interact with the software? Take note of any expectations that were not met or, better still, completely disrupted. Was there enough guidance? Were the functions too difficult to discern?
  • Identifying the kind of prototyping required: Does the project call for “throwaway prototyping” (aka “rapid prototyping”), or will it be more successful with evolutionary prototyping wherein a robust prototype is built in a very structured manner and then consistently refined from there
  • Look and feel: Depending on which technique you’re using and whether you’re casting a lo-fi or hi-fi prototype, you can gain an insight into what that user experience should look like and feel like, using code; this is usually the moment designers and developers must work together
  • Potential problem spots: After getting the user involved and observing them interacting with the software, prototyping can help highlight major issues on interaction, glitches, and unexpected bugs

Source: “Prototyping in a scrum environment“, CapGemini, Slideshare

You can clearly see, by now, that prototyping and agile methodology is a very complementary and intersectional process. It can even allow you an iteration on every possible version of your design or feature.

The whole point of prototyping is to afford you, the developer, key insights that might have stayed hidden until the “final” version, causing major failures and skyrocketing costs to try and “fix” once a project has gone live.

Source: Unsplash

 

Traditionally, there are various methods of prototyping, for both software and design. As we’ve seen above, some forms of prototyping are more conducive to a particular “stage” in the development process. 

But there are various tools and methods you can use to prototype for apps and software. 

So let’s focus on the trifecta of paper, digital and wireframe prototyping, taking a look at the advantages and disadvantages of all three. 

Paper Prototyping

Perfect for “rapid” or “throwaway” prototyping, paper prototypes are perfect for brainstorm sessions, working well during the early stages. Paper is easily accessible and ideas can simply be placed on a page. Paper prototypes are also quite “lo-fi” — though there is an app out there known as “POP” that turns sketches into interactive iOS and Android prototypes. 

Source: Prototyping On Paper

Simple screens are drawn on paper and configured to mimic a digital interaction, switching the sketches according to user behavior

Advantages

  • It’s fast to get ideas down
  • It’s inexpensive, which is beneficial during the initial planning stages
  • These lo-fi sketches can be used later on as the basis for documentation

Source: Unsplash

Disadvantages

  • At this stage of ideating, you could be gaining false positives, there’s a risk of confirmation bias where your ideas essentially remain untested.
  • Not realistic (yet).
  • Because your paper prototype has no connection with its users, it cannot forecast user flows, it’s not interactive and so there is no sense of anticipating reactions — how do screen transitions work? What is the functionality behind each static drawing? Reactions are missing and this is crucial, especially when approaching development from a user-centric point.

At the end of the day, paper prototyping is only useful for the early stages, when most of a project is still abstract. The further you get into the design process, the bigger the gap between paper prototypes and the final product.

Digital Prototyping

Digital prototypes are the most common form of prototyping and are realistic enough to accurately test most interface elements.

Digital prototypes can be built using apps and software made specifically for prototyping. You can even make simple digital prototypes using presentation software like Powerpoint or Keynote.

Advantages

  • Can incorporate realistic interactions and animated transitions
  • Are extremely flexible: it’s easy to edit, enlarge, refine and share
  • Speed: Paper prototypes have the edge on getting the idea down but digital prototypes with a computerized interface can do more, faster — they can be transferred, marked up and widely shared and distributed

And while speed varies from app to app, most have user-friendly interfaces and features like interactive elements or drag-and-drop.

Source: Unsplash

Disadvantages

  • There is a learning curve: Before you can build your prototype, you’ll need to learn the software. According to the survey results showcased below in the State of Software Development graph, 17.58% of developers say the most limiting factors of new tools are the amount of time it takes to learn it.
  • Transitioning to code: Depending on the software, translating your designs into code can be a hit or miss and incompatible elements might get lost in the transition. At some point, you’ll have to address these and code these from scratch.

Source: The State of Software Development 2018

Wireframes for prototypes

Wireframing software is a kind of digital software or app also made specifically to outline the elements of a new development project. It can be as “hi-fi” or “lo-fi” as you’d like. However, wireframing gives designers and developers the greatest amount of flexibility. 

Using wireframing, you can employ evolutionary prototyping, which is all about building a solid blueprint up front and then constantly refining as the project brings in more user data. 

Wireframes are a graphic structure of a website or app. However, they also include details on transitions, buttons, animation, user flows, features, screens and more. Wireframes can incorporate multiple situations of usage and so they’re perfect for A/B testing. 

It’s a graphic structure of a website or app containing the content and elements.

Source: Axure

As a kind of layout design and a master blueprint, rather like the plans for a house or a building, wireframes have three broad levels:

  • Contains the main information
  • Draws the outline of structure and layout
  • Incorporates the visuals and descriptions of the user interface

Source: Axure

Experiment now or forever hold your peace — that’s what prototyping is supposed to be all about. Prototyping gives both designers and developers the license to ideate, create, test and refine. 

Lather, rinse, repeat because this is when things are allowed to “go wrong”.

Share this post

Business Value of Design

wallpaper
Attrecto team

Attrecto team

Business Value of Design

Boosting Your Business Value With the Power of Seamless Design

Companies with a greater emphasis on design seem to win out in every sphere. From revenue to customer satisfaction, greater levels of growth and more predictable long-term sustainability, the power of seamless design is doing more to boost business value right now than any other singular investment. 

It may have something to do with the fact that better design starts with a customer-centric approach and culture. An alignment, in other words, with internal and external priorities. And while numbers don’t necessarily give the whole picture, like scaffolding, they help support decision-makers as they take a closer view into the details of the structure. 

Certainly, that’s what McKinsey’s groundbreaking study on design for better business value shows both shareholders and company executives, allowing us to examine:

  • Why companies with design-led experiences are on the up-and-up in every way
  • What the elements are that are absolutely integral to bringing business value
  • The specific, actionable principles each company can incorporate to experience the promised land of growth-revenue-brand-longevity through something like design that, when it’s working well, is supposed to quietly move into the background 

Let’s take a look.

 

Convergence is Upon Us


Two minutes into a conversation at a networking event, a UX designer who’s asked what his work actually consists of struggles to come up with just one neat little phrase that might cover the breadth of value that design brings to the company’s business. 

If he were doing an AMA session at a conference, he might stay silent and simply pull up this oversized Venn diagram to try and succinctly respond to the question:

Design Disciplines creating business value

Source: Visual.ly

Research by McKinsey reveals a very clear reasoning for incorporating, enhancing and focusing on the way in which design is actually the purveyor of professionalism, productivity, and profits. 

Of 100,000 design actions surveyed from the design practices of 300 publicly listed companies within a five-year period, Mckinsey found that good design equals “superior business performance.”

Known as the “McKinsey Design Index,” top performers were those that showed the greatest improved financial performance, in accordance with four broad design principles. Companies with top-quartile MDI scores outperformed the standard industry benchmark “by as much as two to one.” 

Design focused companies generating more revenue

Source: McKinsey Design Index  

To understand why design is so integral, let’s go back to that Venn diagram. The most obvious takeaway is that the lines are blurred between disciplines, and each intersects and converges — to a greater degree than ever before. 

The reason that companies with specific design practices perform significantly better than their competitors is because:

  • Excellent user interfaces and customer experiences are a standard expectation (with tangible benefits like increased user retention, more targeted marketing budgets, greater levels of profitability due to customer satisfaction and brand loyalty, etc.)
  • There is a major level of convergence going on, not only in the operational “backend” of companies but in the physical and digital worlds (think omnichannel shopping experiences and QR codes), along with a blurring of lines between products and services (think Microsoft’s branch into cloud services, under Satya Nadella, responsible for the greatest profits in Q4 of 2017)

 

Elements of the Design Process Integral to Outstanding Business Results


The design process, in the context of direct financial performance and revenue generation, comes down to four broad but essential components. 

  • Analytical leadership: Being able to implement the software, tools, and technology that measure the drivers of design performance with the same rigor, focus and deliberation as revenues and costs
  • Cross-functional talent: Nurturing teams of designers and developers that work together, along with the structures — like running sprints — that make user-centric design part and parcel of everyone’s focus or job, rather than being siloed to one department
  • Continuous iteration:Making the development process a risk-reduced process by continually listening, testing, and iterating with end-users
  • User experience: Bringing together the disciplines and measurements of physical, digital and service design, especially breaking down the internal or operational walls

We’ve already seen “data-driven” decisions. But what about “design-led decisions” in improving business value? 

This matters now more than ever because of the opportunity that businesses have to tackle their processes from a standpoint of cost-efficiencies, rather than cost-cutting. 

You see, large- to medium-format enterprises can learn a thing or two from the behavior of lean start-ups, which must rely on prototyping and iterative learning in order to keep their development fiscally responsible and sustainable. 

Business value focused design

Image source: Unsplash

Design-led decisions will also become increasingly important as we rely more and more on large swaths of user data and AI as sources of new insights. These advances and technologies will call on new techniques that are themselves guided by design, such as computational design and analytics. 

We’re already seeing that rapid access to a multitude of interactions with real customers means a better ability to reach out at just the right moment, or present just the right offer, and create a conversion.  Now, these interactions are fractured through multiple channels, especially over social media and “smart” mobile devices. 

These pivotal developments are ongoing. Nearly all of them call for the user remaining at the very center of all process and design considerations. But that also means they’ll need to be at the heart of business decisions because user design is driving priorities forward. 

Five Principles of Design-Led Customer Experience


How do we make elements like analytical leadership, cross-functional talent, continuous iteration and user-experience across disciplines guide customer experience? What are the actual practices that businesses looking to enhance their value will need to focus on?

1. Understand the customer’s needs and perspectives

Design is the differential that makes all the difference to the customer. Their delight at novel experiences and their satisfaction derived from an app that not only anticipates their needs but simplifies the process and delivers them the end result they’re looking for — these all translate into a heightened user experience, a preference for the product or service the company offers. 

Every software development or web app development project begins by creating a repository of a customer’s needs and perspectives that come from the goal of the app itself. What needs does the development fulfill?

A customer’s needs and perspectives are not just the starting point. In agile development and design-led customer experience, it’s the guiding principle of all future changes, versions, and patches.

Customer needs focus in business value analysis

Image source: Unsplash

2. Draw inspiration from other industries

While design-led experiences have been in play for a long while now — think, Apple’s obsession with beautiful type and font faces evolving to beautiful user interfaces — the way to stay innovative and question the norms is to draw inspiration from other industries. 

Consider, for example, the nature of “biomimicry.” It’s an approach where designers and engineers look to nature’s most fundamental mechanics — the scales on a fish for protection and light reflection, or the photosynthetic process of plants to understand and “mimic” energy conversion — in order to solve complex human problems through design.

3. Get a glimpse of what’s on the horizon

Because design-led experiences are half experimental and exploratory, half guided by actual customer need to develop a real solution, the resulting solution (in the form of a product, service or even feature) can be creative enough to actually pave the way for a new iteration on an upcoming trend. 

This is also why iterative approaches to design and development are so useful — they harness the power of a collective team, through structures like sprints, in order to find a solution but pave the way for something entirely new. 

4. Empower multidisciplinary teams

Design-led experiences call on the convergence of expertise, of more than one function to build something as robust as an app, enterprise software or an interface. 

There is also a convergence between the physical and digital worlds, as well as products, services, and environments. 

A great example of this is augmented reality, virtual reality, and artificial intelligence. The software “AdMind,” for example, uses predictive analytics and artificial intelligence to manage and deploy more strategic Adwords campaigns.

This convergence calls for an evolution in the way that teams work. Remember that, in order to use design as a boost to business value, it must not be siloed off as a singular department’s priority — instead, it must remain at the fore, with cross-functional teams making it a point of focus in their own respective disciplines. 

Designer team's role in creating business value

Image source: Unsplash

5. Use agile techniques to prototype experiences and business models

Agile development for an app development company syncs quite effortlessly with design-led customer experience. 

It’s a methodology for development projects that not only empowers teams to work together in an iterative and innovative manner, it’s also a process that puts the user right at the heart of all its actions. 

This iterative approach also offers a better way to incorporate customer feedback and research into the project. It’s never quite the “end” with Agile because development is ongoing. And at the heart of this development must be the user. 

Besides a design-led approach to customer experience, there’s one more thing that McKinsey’s top successful companies have realized: the boundaries between products, services, and environments are necessarily blurred. 

An “integrated” and cross-functional view is not only necessary in order to design valuable end-to-end experiences for customers, but it also gives businesses the competitive advantage they need. 

Convergence is, in fact, completely changing the rules of the game. The best way to keep stable business profits is to bring business value through design that focuses on what the customer needs. 

 

Share this post

SCRUM Master vs. Project Manager – Who to hire?

Designer team's role in creating business value
Attrecto team

Attrecto team

SCRUM Master vs. Project Manager – Who to hire?

The Manager and the Master: Choosing Between A Scrum Master and Project Manager

What’s in a name? When it comes to Agile software development, does differentiating between a Scrum master and a project manager really matter?

To be brief, yes, it absolutely matters, and no, they are not the same. 

Understanding the differences between a Scrum master (SM) and a project manager (PM) requires us to clear up a few things first:

  • They might be “similar,” but they’re not interchangeable; Scrum masters and project managers are mutually exclusive
  • One person cannot (and should not) fulfill both roles. 
  • It’s way more than just a title — The “SM” and the “PM” are actually psychologically and professionally conflicting
  • If transitioning from a Waterfall method of development to Agile, don’t expect roles to simply move over in a one-to-one alignment
  • Without a Scrum master formally assigned, management has more of an incentive and ability to veto any optimizations or Agile behaviors that might challenge their vested interests

Source: Unsplash

While both operate from a similar base of knowledge, their roles and functions are different, so their focus and their vested interests are different too. 

To quote Ghostbusters: “Don’t cross the streams!”

Why the mix-up?

Because Agile project management is the noted industry standard today, associated rules, roles, and practices have not only exploded, but they’re being adopted across the board — often, without a sound understanding of the 12 Agile development principles in practice. 

Similarly, the term “Scrum master” has become a buzzword. And it’s not just customers who want to see it in action — plenty of teams are following the trend of instituting a Scrum master. 

But what we want isn’t always what we need.

The new-and-shiny-object syndrome afflicting the Scrum master seems to have left the role of project manager in the dust. Often the latter is now seen as archaic, “old-fashioned,” and constantly at risk of slipping into obscurity. 

But this perception is far from the truth. 

In fact, this “perception” fails to understand the important distinction between the two roles. 

There are moments where only a Scrum master can do what needs to be done, and there are functions that only a project manager should be handling. 

Let’s take a look at what these specific roles are, when teams should rely on each, and what operating in the “zone of genius” for each role really looks like. 

What does a Scrum Master do?

Between the project’s development and the customer’s requirements sits the Scrum master. They are coaches, facilitators, guides, defenders, protectors and nurturers of ideas and processes within the Scrum.  

Within Agile project management, the responsibility of the Scrum master is narrower than the project manager. 

The Scrum master supports the product owner (who is the supervisor and could very well be the project manager as well) by guiding the Scrum process, its proper implementation and the optimization of its benefits. 

As part of a larger team, Scrum masters are responsible for daily standups and the tasks related to this. 

It’s up to the product owner to refresh and maintain the product backlog, which describes the product, its requirements, the customers it is serving and more. 

The Scrum master then handles the operative tasks that respond to the product backlog and these requirements. They also handle the development tasks surrounding the changes in requirements, which naturally evolve as more information comes to light and the project progress and evolves. 

In this support and facilitator position, the Scrum master can help “dodge bullets,” so to speak, keeping developers focused on their main priority: developing and problem-solving to iteratively create the best product they can. 

Source: Unsplash

When the product owner adjusts and re-prioritizes the backlog to fit changes and steer the project, it’s the Scrum master who, working as a ship’s first mate, guides the operation, looking at the project from all angles. 

The ultimate decision-making power, however, rests with the product owner — it’s their responsibility to ensure the project is moving ahead. 

However, when in doubt, and for clarification, they’ll turn to the Scrum master to help answer questions about user experience, deal with issues on functionality, to gain feedback and insight from users and when they feel the need to realign development to fit with business changes. 

If a customer provides a skilled project manager or product owner on their side, then the Scrum master will be someone on the development team who will need to handle these kinds of operative tasks. 

Luckily, the role of the Scrum master is to help this individual understand better how to effectively manage the work of the team using the product owner’s own product backlog, planning, and running review meetings.

What does a project manager do?

You might notice that, while describing the role of the Scrum master, we ended up defining the role of the project manager. Oftentimes, the product owner is the project manager, and they are responsible for communicating with the customers on a daily basis, identifying the concrete development tasks.

The project manager then returns to the development team and must constantly and consistently outline and feed the team with these tasks. 

Decision-making is ultimately (and firmly!) in the hands of the project manager, and they must finalize the feasibility of the development along with the customer, then break it down into concrete and executable tasks for the development team.

Source: Unsplash

It’s also within the project manager’s purview to prioritize these tasks while working with the Scrum master about the deadlines, used and remaining resources (which are, most likely, development hours).

The project manager is responsible for maintaining and running all functions, approval, and task-management related to a project management tool like Jira, Trello, ASANA, etc. They validate change requests (CR) with the customer, having a stronger customer viewpoint (and, thus, a stronger interest) than a Scrum master.

When to choose which?

So how do you know which you need? 

You need a Scrum master if:

  • You have a product owner in-house, and you are breaking down the development into small tasks
  • You are using Agile methodology exclusively
  • Your developers can work without strong supervision

You need a project manager if:

  • You want to give higher authority (e.g., decision making) to a designated person
  • You are using mixed methodology (elements from Agile and Waterfall)
  • You need someone who can maintain your backlog, your task list, and the administration

It should be clear why the two roles cannot cross: They have fundamentally different focuses. To cross them would produce a conflict of interest. Their operations also require vastly different viewpoints. 

Source: Unsplash

The project manager liaises with the customer and the project, actually handling its progression, keeping the customer’s interests and needs in mind. However, the Scrum master must focus singularly on the operations, the “meat and potatoes” of the development process, going between the project manager and the developer team. 

Share this post

The truth about the accuracy of software estimations

Programmers working on computer program
Attrecto Team

Attrecto Team

The truth about the accuracy of software estimations

Have you ever heard of a “Standish Chaos Report”? Trust software developers to come up with fantastic terms for an otherwise prescient trend occurring in development projects: the incidence of project failures and the factors that contribute to them.
The failure records of software projects in the United States alone is quite staggering. According to the Chaos Report

  • 31.1% of projects will be cancelled before they ever get completed
  • On average, across small, medium and large enterprises, over half of projects will cost 189% of their original estimates
  • While companies in the U.S. spend more than $250 billion each year on IT application development, spanned across approximately 175,000 projects, only 29% of these are ever counted as “successful
  • Meanwhile, Tricentis estimates that software failures cost the U.S. economy up to $1.7 trillion in financial lossesSource: Chaos Report 2017

The truth is that poor estimation can lead to a score of issues, besides simply a time or cost overrun.
It can lead to changing requirements, poor testing practices, software vulnerabilities, glitches, bugs and overall “challenged” projects doomed to reproduce technical failures if launched merely to meet cost and time budgets but not quality standards.

Source: Software Fail Watch — 5th Edition

In a survey of the negative effects and the “erosion” of value on a brand, Tricentis found that, in 2017, consumer tech companies were most vulnerable, with software challenges spanning everything from cost overruns, failures and recurring bugs.

So why aren’t estimations more aligned with the project’s development and parameters?

If failures are occurring consistently, costing companies more than just money — crossing the boundaries into brand equity and power territory — then why can’t we aim to use better estimation methods on projects?

The Cone of Shame

Dog-owners will know how much their furry friends resent the cone of shame.

Software development and estimations are not too fond of the cone either. In our case, it’s the Cone of Uncertainty that hangs, like a dark specter, looming above the commencement of every single project.

Where there should be enthusiasm and anticipation, there is dread. Even though we’re eager to roll up our sleeves and learn from our “past mistakes,” there’s still an edge of uncertainty when we recast our estimations for projects.

In almost 30 years of software development project studies, expert research has concluded that initial estimates on a project can vary as much as four times more or less because neither the estimating team nor the client can yet fully define the scope of the project right at the outset.

In the “waterfall” method (which is the classic approach to development), the Cone of Uncertainty tracks the variance in these estimate-versus-reality scenarios.

As time progresses, a greater amount of the project reveals itself and the scope narrows — which then trickles down to a tighter estimate and a reduction in uncertainty.

Source: Envoc Glossary

But — you knew there was a “but” coming, right? — can we reduce uncertainty to a greater extent and even earlier in the process? Notice that a “reduction” doesn’t have to be an elimination in order to make the project successful.

There are three specific aspects of software development that the brooding Cone of Uncertainty affects:

Consistently “good” products — Maintaining a product or project’s quality requires a particular standard to be set and achieved in a short period of time. Software projects usually have changing features, according to customer needs, and this calls on either a greater level of agility (towards deployment) or more certainty, earlier on in the project’s development.

The requirements of “custom” built software The Cone of Uncertainty undercuts the amount of foresight and planning that custom software development requires. The latter is more about engineering, where even the foundational building blocks must be custom-built. Integrating these building blocks then initiates multiple possibilities and logical paths to be covered so teams will need to constantly refine these concepts.

The ongoing nature of development  —As the Cone of Uncertainty progresses over time, the variance in estimation versus reality reduces. But using the waterfall method also significantly bloats the time that teams spend in the phases of “What are we building?”, “How does it work?” and “What will it look like?”

So we know what those failures look like — but what about success?

In its survey of IT executive managers, the Standish Group’s “Chaos Report” found that, besides user involvement and executive management support, a “clear statement of requirements” (i.e. scope maturity), tied into proper planning can yield overall consistently successful project results.

Source: Chaos Report 2017

The Cone of Uncertainty, however, seems to make even these success criteria seem less than certain.

How can we hope to have more accurate estimations in an ever-changing environment?

Because the consequence is not only a possible failure or a particularly tricky bug that could, as in the case of Provident Financial, a U.K.-based sub-prime loan company, result in a £1.7 billion loss, the largest one-day share price plummet and a CEO resigning over the fiasco.

Factors Affecting Estimations
Now that we know what failure looks like (and, worse yet, feels like), let’s take a look at the factors that affect the estimations on a project.

Massaging the scope into proper maturity

Scope maturity is tied into estimations on software projects. During the planning phase, the development team will need to finalize requirements and think through the requirements from a few different angles.

But the Cone of Uncertainty almost guarantees that designing and anticipating everything up front is almost an impossibility — especially with proper depth.

So what is the solution?

Favoring the incremental approach helps smooth out the development process, making it much more responsive, shortening the initial phases of variance within the Cone of Uncertainty. That’s because the “responsibility” of accurate estimations is spread over the whole development.

In our own experience with developing a web app that models a Digital Transformation Company’s internal processes, we had two parallel goals: to lay down the foundations of a long-term project and to deliver features within hard deadlines.

The custom solution needed to be the only app/tool the business used for internal researching, analyzing and planning. So we allowed the scope to evolve to maturity along the way, using our automated deploy-and-build process.

This bias for agile development is also what enabled our QA team to provide the best quality code for the client.

Concept elaboration
Estimation accuracy relies on more than just scope maturity — it also calls on the elaboration of the concept.

With custom-designed software projects, there is an opportunity, as with digital transformation projects, to use the principles of continuous and iterative building and deploying in order to mature the project in a way that costs less time and cost up front.

But this also calls on developers to have a firm grasp on the concept or specification up front.

This is one factor in estimations that provides more control than others. Teams will no doubt have to perform sprints and rely on breakout sessions to really get to the heart of the concept.

The details uncovered therein for the requirements on a project — such as problem, solutions, features, technical requirements, marketing requirements, etc. — can help anticipate a more aligned budget.

The point is to get as detailed as possible because details uncovered after tells the development team that an estimation was based on basis of flawed assumptions.

Change requests

You may have noticed by now that time is the wily variable that can bog down or uplift a project. Certainly, development teams are always racing against time to capture the right scope and concept.

It’s a reality our team has come across in our over eight years of development and one that especially pitted us against time during a project for Mitt Telenor’s official iOS and Android app.

If the product is set to launch at a specific date, we need to keep CRs at bay and be transparent with the client about how their ever-changing concept puts their project at risk of running well beyond the estimated project numbers.

CRs may well be warranted — but if they’re not anticipated, as agile SCRUM methodology allowed us to do with Mitt Telenor, the project can quickly become “challenged.”.

Source: Chaos Report 2017

Change requests and re-writing code are tasks that fare best in shorter, more responsive sprints.

In the case of Mitt Telenor, these short sprints are exactly what allowed us to uncover issues at an earlier (and more critical) point in development. This then allowed us to keep the development lights on, so to speak, continuing in a more self-aware (or, rather “software-aware”) manner.

The Place of Estimations in the Agile Methodology
To handle these changes and deliver a successful project, both parties (Client & Developer team) are better off with an agile methodology.

Agile allows us to be incremental, responding to a change in business as well as project needs in a more natural way. It’s also easier and more realistic to estimate and then implement changes in small increments, at closer intervals.

Software development is all about change, by its very nature. It is not now, nor has it ever been, a static undertaking. This is why development cannot employ a templated approach, especially in the landscape of digital transformation.

Source: Envoc Glossary

Notice how the Cone of Uncertainty here is significantly leaned out, from its original bloated physique. The result of a consistent diet and exercise? Not in this case. This is the benefit agile methodology brings to the table.

You’ll notice that we’re not claiming that we can simply eliminate or mitigate the Cone of

Uncertainty — no. To do that, we might as well not embark on a development journey at all.

What agile does allow us to do, however, is to drastically reduce the time spent at the initial stages, those questions of:

  • “What are we building?”,
  • “How does it work?” and,
  • “What will it look like?”

And the rest of our time? Well, instead of hemming and hawing, thinking and scratching our heads, only to come up with shaky estimations that are flawed at best and wrong at worst, we can spend our time in our zone of genius: Development.

Indeed, the “development” zone is where our initial estimates are proven or adjusted, requiring less upfront and overall time, and with greater accuracy.

A more aligned estimate and a smoother planning process.

That’s the advantage of agile

Share this post