devxlogo

Jump in the Water’s Fine: Implementing Agile

Jump in the Water’s Fine: Implementing Agile

Why Trust Us

o you have decided to implement Agile at your company. You like the ability to track the teams progress using velocity charts, and the close customer communication. The ability for a software team to release software frequently (at the most every month) is attractive as well.

What is the best way to introduce this? There are many ways to implement Agile in IT, the following are experience based recommendations.

Introducing Agile to a Software Development Team

The bulk of the literature about Agile methodologies is related to software development. In fact, Agile was developed in software development teams. See “Agile, a Different Methodology” for more information on the background. For that reason, introducing Agile first to an application development team makes sense. If your team is one or 200, there is something in Agile for all sizes of teams.

If your group has no experience with Agile, use a good consulting group to do at a minimum an immersion class for the developers. This is the best way for all devs to get jump started into doing Agile.

The different methodologies include Scrum, XP, Crystal, FDD, Lean and others. The methodology with the most adoption is Scrum. We will touch on standard Scrum practices initially, and mention some newer Lean ideas used in software development as well.

Keep in mind that Agile/lean practices promote continuous improvement. Even though when the team first uses Agile practices, there will be mistakes. The beauty of using practices like breaking requests into smaller features/stories, and frequent iterations is that those mistakes will be caught early.

Continuous improvement helps to make sure that mistakes happen less frequently and waste is eliminated. For instance, three months after using Agile, the team may change their estimation method based on experience.

Starting a New Project with Agile

Once the Agile training or immersion class is done, the team is ready to begin. Start the project as soon as possible after training, to keep the training fresh in the teams minds. One core Agile concept is the self directed team. Have the team decide what practices to implement in this project. This means, the kickoff meeting is the place where the Scrum master, or team leader, leads the team to determine the following:

    * Breakdown of work (use Features or stories for instance)
    * Length of iterations (in the case of lean length of releases)
    * Team Room (recommended)
    * Testing discipline (use TDD? Recommended)
    * Preparation for Customer demo/planning meetings
    * Estimation practices (use planning poker or other)
    * Release planning
    * Definition of Done

Daily standup meetings of 15 minutes are not considered optional. In these standups, team members who are doing work (usually developers, analysts and testers), communicate to the team leader and stakeholders. This communication takes place by each team member providing the answers to the following three questions.

    * What did you do yesterday?
    * What are you working on today?
    * Are there any roadblocks?

If you have a large team (more than 10 developers, analysts etc.), then consider having only blocked team members communicate. If this restriction is not put into the standup, then this daily meeting can take a lot of time that may not be necessary.

See also  AI's Impact on Banking: Customer Experience and Efficiency

Breakdown of Work

The breakdown of work is critical to many of the other issues mentioned. Estimation planning is dependent on what size of work the team is using. Customer planning expectations depend on what size of work items are selected as well.

Features may make more sense to customers. If your marketing person wants to let external customers know what will be included in the next release, features can be useful.

The definition of features from Feature Driven Development is as follows: “Features are granular functions expressed in client-valued terms using this naming template: . For example, calculate the total of a sale, calculate the total quantity sold by a retail outlet for an item description. Features are granular in accordance with the rule that a feature will take no more than two weeks to complete, but not so granular as to be at the level of getters and setters. Two weeks is an upper limit; most features take less than this time. When a business activity step looks larger than two weeks, the step is broken into smaller steps that then become features.” Using features allows customers to define what they want at a higher level than the developer might. For instance, if you are working on a travel web site, one requested feature might be “Allow Customers to Save a trip for future purchase”. Many Agile practitioners like to break a feature like this into more detail for the developers. This detail takes shape as appropriate tasks or stories. The team defines the tasks or stories once the customer selects that feature for the next iteration. It would create waste to define those tasks and stories before they were selected. Features originally created may not be selected ever, so spending any more time on them would be waste. Only work on what the customer has requested, do not over engineer.

In the first customer planning meeting with the team, the customer will select the first features to work on. Being the first meeting, the team will not demo anything, since the customer has selected any work items. The team leader (most likely) explains the meeting structure to the customers/stakeholders that meet in the planning demo meeting. This includes standard project management issues like the communication plan (daily standup meetings, planning meetings), change management (planning meetings allow the customer to change their minds on priority without a lot of ceremony). The first meeting also must have the customer understand the type of work items the team is using.

The customer needs to understand that they are in charge of priorities. The customer and team define what is meant by done for this project. By definition of done, XP prefers that the customer helps the team define an automated acceptance test that the team can use. The first meeting will normally take more time than the standard planning meeting, so set the meeting time accordingly.

See also  Should SMEs and Startups Offer Employee Benefits?

Passing the automated test does not mean that the feature is complete, but that it is ready to be included in the release. It is recommended that done means that feature is released version. In a web site, if it could be released to production, that would be best.

Length of Iterations or Releases

Iterative development is the clarion call of Agile development now. I actually do not know what clarion call means, but thought it added some flavor to this article. The point being that most articles etc. associate Agile with fixed length iterations. But Agile is really about short feedback cycles, not necessarily fixed length iterations.

To clarify, fixed length iterations are defined by the time allocated for the team to finish selected features/stories. The number of stories selected are based on the teams past performance. So if a team has consistently finished two features in an iteration of two weeks, the customer can select two features for the next iteration. During that fixed iteration, the customer cannot change the feature selection.

Lean development methods recommend a different approach to iterations. Instead of fixed length iterations, the team commits to release frequently, in a time frame similar to fixed length iterations. But the customer prioritizes all the features, rather than selecting a set number of features for the iteration. Team members, who have finished their task, story or feature, pick the next highest priority from the backlog.

For release or fixed length iteration, the team decides the length of either. The recommended length is normally one to four weeks. Shorter is considered better, since the length of the iteration determines the feedback cycle. Many do not like one week length times, but the shorter time frame can help focus the team.

Team Room

Make a team room! This cannot be emphasized enough. There is literature that points to the benefits of team rooms. The benefits include close communication between team members. The team can also have fun, which can’t be discounted.

Surprisingly, many team members may want initially to work in their cube, rather than in a team room. While the team should be self directed, make a pitch for this, it is worth doing. The team may not pair program, but the ability to immediately lean over and look at someones code for answers helps speed the team. Also, with everyone working out in the open in the same room, without a personal phone close by, multi tasking is discouraged.

The team room should be a conference room, or a “war room” type area, that can comfortably house the team. For large teams, the team room, may be split into multiple rooms, like feature crews.

Testing Discipline

The team should decide about unit testing. TDD is recommended but the discipline may not be available in the team. Start out requiring unit tests for all features. A team meeting with some examples of good TDD and unit testing examples can help the team to understand this practice. If this practice is not new to the team they have a head start.

See also  Should SMEs and Startups Offer Employee Benefits?

Automated Acceptance Testing is recommended as well. This means that the customer will need to commit to helping to understand/write tests. This is a recommended best practice that will help in years to come as changes are made to the application. With automated acceptance tests, change in business logic that contradict older business logic are easily spotted. These can be clarified with customers before they go to production.

Look at Fitnesse, rSpec, and Selenium as some open source options for automated acceptance tests. You can try using this without software costs, just time costs.

Estimation Practices

So how does the team know if their work items are the right size? One way to answer this is to use the planning poker method, popularized by XP. Planning poker allows the wisdom of crowds to help give an estimate.

To use this method, first admit that our estimates are wrong. I do not know any software estimates that are consistently accurate as to amount of time. But if a team does estimates using a metric like a point system, the work items estimated tend to reduce variability over time.

To estimate using planning poker, teams sit together and they vote on the size of each story. If there is a story like “A Customer can log in to check their latest orders shipping status”, each member of the team votes on the effort to complete that story. Many teams use the Fibonacci sequence as a way to “score” each story. That sequence starts as 1, 2, 3, 5, 8, 13, 21 … Another method is called shirt sizing. Shirt sizing uses measures like Small, Medium, Large or some variation of sizes. The number does not mean time, but it does represent level of effort to the team.

I recommend the book “Agile Estimating and Planning” by Mike Cohn, as a good starting point on Estimating. As your teams mature, there become better ways to estimate, to eliminate much of the time spent on estimating. There is much discussion on this topic in lean software development circles.

Once your team has been working for a few weeks, their estimates should show consistency. The team sees how many points they complete per iteration or release. Over time that number will smooth out to be very consistent. Occasionally the team encounters difficulties such as new technology, or domain specific issues that slow them down. But over time, the number that can be completed is consistent.

Now that your team has jumped into using Agile methods, the journey is not over. The idea of using Agile/Lean ideas is to continuously improve your processes. Keep in mind that customer value is key to provide, and keep your people who add value in the center of that process. Agile and Lean methods push responsibilities down to the team level, so embrace that philosophy.

devxblackblue

About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist

Charlie Frank

Charlie has over a decade of experience in website administration and technology management. As the site admin, he oversees all technical aspects of running a high-traffic online platform, ensuring optimal performance, security, and user experience.
View Author
Show More
Linkedin Twitter

©2024 Copyright DevX - All Rights Reserved. Registration or use of this site constitutes acceptance of our Terms of Service and Privacy Policy.

Sitemap — Privacy Policy