We hear a lot about organizations using Agile and Lean software development, but what are the specific benefits? I talked to leaders at Ci&T, a services company specializing in Agile and Lean, and asked what they felt were the top five ways that Agile and Lean development can be used to get the most out of software projects and overcome typical challenges. Read on to find out how Leonardo Mattiazzi, VP of international business, answers.
Bringing the business user to the project
Agile methodologies combined with Lean principles requires the involvement of business users--
those who will use or benefit from the application being developed-- to be deeply involved
throughout the project. Instead of getting detailed specs from these users prior to development, as
in traditional waterfall methodologies, the requirements will be discussed in every sprint, and the
resulting software will be shown at every demo meeting to those same business users. The feedback
comes early and often, and the end product is a lot more likely to meet those users' real needs.
Not surprisingly, this is also probably the single biggest challenge in
Requires Free Membership to View
Agile/Lean
projects, since business users are accustomed to the status quo and may feel that they won't
have the time to make themselves available to the project team. Only quick-wins (making some
business users smile from ear-to-ear with actual results) will overcome this challenge. Bringing a
peer that has already felt the benefits to share his/her experience is a good strategy to break
through initial resistance.
Uncovering problems that otherwise could prevent a successful launch
A very common picture in Lean manufacturing is a boat navigating a river with a big rock under the
water (or an iceberg in the sea, if you prefer). If the water level is high, the captain may not
see the danger and crash into it sooner or later. If you lower the water level, you can see all the
rocks and deal with them. In manufacturing, the water level is a metaphor for inventory levels, and
that is the justification for just-in-time delivery. Likewise, in Lean software development, having
a problem solving attitude and the need to deliver a new release every two or three weeks will help
developers anticipate issues that otherwise could be detected only a few days prior to an important
product launch. It's shifting from a firefighting mode at the end of the project to a constant
alert, roadblock removal mode throughout the project. Unfortunately, constantly talking about
problems isn't pleasant and some people may be reactive. However, by doing this the issues will
never be as big as they would if accumulated until the end of the project - when a solution may
even be impossible to find. The key is to have a positive attitude towards problem identification
and problem solving, and having everyone educated about the new modus operandi.
Establishing a pace to the project
A common complaint about the traditional waterfall SDLC is that you never know how the project is
really going. There are milestones, but as the deliverables at these milestones are so distant from
the final software, you never really know what is left to be completed, and it's very hard to set
realistic expectations. More often than not the famous adage "80% of time to complete the final 10%
of the project" comes true. With Agile's fixed sprints (time-boxed windows), a certain amount of
software is delivered at a constant pace (usually every 2-3 weeks). All stakeholders can see the
speed of development, and expectations are set based on direct experience, not vague promises. The
challenge here is to tame users' general tendency to want everything delivered in the first sprint,
which brings us to the next topic...
Prioritizing according to business value
Notoriously, every single feature is equally important in a software development project... Until
you establish a cost point and a value point to it. As simple as it may sound, it may be shocking
to know how many (few) project teams actually do this type of prioritization. But as one of the
most important tenets of Lean is value generation and waste elimination, dropping off features is
not shameful; on the contrary, "less is more," if you are focusing on what is really important.
This prioritization mechanism is something that business users (and business-conscious IT folks)
can grasp very easily (and love), since it's their lingo. We just need to incorporate it in the
day-by-day activities (i.e., make it an integral part of the sprint planning process)-- it can't be
a "once in a lifetime" experience.
Letting people shine
Finally, one of the biggest advantages of Lean management is that it allows talented and
intrinsically motivated people to shine and show their craft. With lightweight Agile practices,
teams have more autonomy-- they are not just unenthusiastically following highly prescribed steps
full of waste where the process is often more important than achieving results. Power flows to the
edge, and the team constantly identifies opportunities for improvement that they can implement
themselves (kaizen). They feel proud of themselves at every demo meeting, and can receive praise
for the good job done directly from the client (the whole team, not just the project manager). Lean
reckons that software development
is done by creative people, not automatons. The potential pitfall here is to confuse increased
autonomy with relaxed discipline or total lack of method. Experienced leaders will not let that
happen.
Leonardo Mattiazzi is the vice president of international business at Ci&T, a global company specializing in web and mobile application development, product engineering and IT services. In his 14 years at Ci&T, Leonardo has witnessed and actively participated in a full-scale trajectory of growth, stumbling, success, transformation, and above all, intensive learning in new approaches to software development. Leonardo has a regular Lean-focused podcast series on iTunes, and blogs about Lean topics at industry outlets that include the CIO Blog, IDG Connect and Nearshore Americas.
This was first published in September 2011
Join the conversationComment
Share
Comments
Results
Contribute to the conversation