You are here

You are here

3 steps for customizing your agile processes

Amy Reichert QA Engineer, RxMxUSA

While several different software development methods fall under the agile umbrella—Scrum, XP, and Kanban, to name a few—the general characteristics of agile development are fairly well-defined. Work is organized in sprints or iterations, and user stories are produced for the development team by product owners or product managers. Developers and QA testers work either seamlessly or as a single team unit. 

That’s all good. But agile development is also meant to be creative and unique to each team. It’s meant to change, morph, and be re-created by every team at every company that uses it. Creativity, uniqueness, and flexibility make for stronger teams and better quality software applications. That's why it’s important to create a unique set of agile practices that meets your company’s needs and actually works for you, rather than sticking to a methodology you purchased training for—as if it’s the only one, as if it’s the sole source of truth and one must never waiver from it. 

Agile is about techniques and lightweight processes that build flexibility into a complex business model. The following techniques can help a team create its own creative agile methods, remain flexible, and ultimately create products that consumers want to use.

Step 1: Blend or drop agile techniques

The first step to creative agile is experimentation. You say you don’t like Scrum or find it too cumbersome? Try Kanban. Of course, many teams find that Kanban in its pure form offers too much freedom, which can drive date-driven teams or development organizations crazy.  The creative agile freedom of Kanban works better for teams that are in the norming or performing stages. However, depending on the tenacity of the team members, it can be successful at any stage.  

Ask yourself if the business and team can work well without defined sprint dates. If so, Kanban is the better choice. Or, if you find the sprints are necessary for organizing units of work, add them back in along with the Kanban board process. Scrum involves certain meetings and discussion sessions that highly productive teams may not feel are a valuable use of time. Again, use the creative skills that your company was built on to determine which agile processes need to change.

Step 2: Determine an agile communication structure

Does your company or team need the structure and oversight of Scrum? If so, appoint a Scrum master and proceed. Does the team need the additional structure, or perhaps only part of it? An agile product owner I know says that a strong Scrum master gives a developing team the direction it needs to be productive. He says, “If my teams get lost in the weeds, so to speak, I bring them back by restating the business purpose we’re solving.”

This direction is especially important when team structure changes and the team is still in the storming or norming phase. Make sure decisions are made, communicated, and then followed by the team—as long as those decisions are effective. When prior decisions become ineffective, change them! Agile is creative and meant to change if necessary.

Scrum, in my opinion, has some built-in time-wasters that can be eliminated or reduced. Daily standups may not be necessary; try every other day or even twice a week. Same with the retrospective meetings for each sprint. Ask the team if they’re valuable, or perhaps move them out to a quarterly discussion rather than the end of every sprint. Why? Because bored software development teams quickly become disengaged when going to meetings that are viewed as a waste of time.

XP relies on communication and knowing where work is in the development process. To track and make project progress visible, a Kanban board fits well with XP. Or you may take the Scrum sprints and build that in for date visibility. Creative agility allows for flexible process creation.

Step 3: Pull in “old school” processes

I love agile, but the way it’s generally used creates significant gaps that often result in process failure. There are a couple of old-school processes that are essential for the long-term success of a software development company and the applications it produces, but these are typically missing as a result of following an agile agenda:

  • Design specification documentation
  • Manual test-case creation and execution

The lack of these processes and documents can wreak havoc over the long term.

Design specs and docs

Design specifications are essential regardless of the format they’re written in. The important part is they are written, updating each release if needed, and stored in a location where team members can find them. As human resources come and go, knowledge of code development and application function can easily get lost. Some agile software development teams are in a constant state of learning, which significantly reduces productivity and is simply exhausting over long periods of time.

Creative agile teams write down the design, including the whys and the hows. The documentation needs to be succinct but detailed enough to be useful for new resource education. There’s nothing more wasteful than new agile team members spending hours trying to figure out how application code functions. One never knows what has been missed until it’s too late, and that does not equal end-user satisfaction.

Manual testing

You shouldn't skip manual testing. Automated tests are essential, but they tend to prove code works, regardless of whether or not the code can be broken. A team won’t find all the defects with all automated testing, but customers will. It’s essential to have a resource to manually develop user-focused test cases that are executed continuously. It will complement the team’s test automation while providing more thorough testing.

Remember that agile means flexibility

There may be more old-school processes that fit into your agile practices, and there may be other processes you'll invent. The only way to find them is to be creative; open your mind and understand that agile means flexibility. Creativity is likely how you got where you are, and it’s what will keep the business and the software applications viable long term. 

Be careful not to wrap the team around rules, but instead experiment and create a unique brand of agile that truly meets your business and resource needs. In this way, you'll sooner realize and maintain the end result of releasing a higher quality product, faster. Creative agile leads to a workable development process for team members that produces software customers want to use. 

How have you and your team blended techniques from different agile methods? Let us hear from you in the comments section below.

Image credit: Flickr

Keep learning

Read more articles about: App Dev & TestingAgile