Agile Methodology has been around for decades, but has been gaining momentum and popularity in the last several years. The Agile process allows for more fluid project planning and execution in order to easily adapt to change, engage the entire team more evenly, and show progress and results more frequently. Due to this, Agile fits well with the fast paced ‘tick-tock’ technology cycle where software and process changes fast
A lot of companies talk about “going Agile”, but are ultimately resist changing their long-held practices.
Even though Agile methodology has gained a lot of traction in the last several years, switching over from an existing, long-standing process to fully embrace Agile can be difficult to accept and implement.
Instead, many companies use certain elements of Agile methodology that suit them, without upending the company’s existing processes.
Here are three elements of the Agile process that you can implement without rocking the boat, and will help lead you to a successful project.
The Daily, 15-Minute “Stand Up Meeting”
The ‘Stand Up’ is probably the most popular a la carte Agile element that companies like to adopt. These stand ups are daily meetings in which the whole team gathers to give a quick update on their progress. The reason it is called a stand up is because you stand for the entirety of the meeting in order to convey the quick and informal tone of the meeting.
Pro –
- Good way to get the pulse of the project, identify issues early and track progress.
Short daily meetings helps the project manager keep on top of what work is being done, and team members know what each other is working on which can help avoid duplicate efforts and understand dependencies. These meetings also help bring up issues the team members are facing, and can identify people who have too much or too little work on their plate.
Pitfall –
Daily scrum meetings can balloon into daily, hour-long status meetings if they are not managed properly.
Insight –
The daily stand up meetings are not meant to be status meetings, instead each team member should answer only 3 questions:
- What did you work on yesterday?
- What are you working on today?
- What are your obstacles?
It is the Scrum Master/meeting leader’s responsibility to keep the meeting short and on-topic. If anyone needs to expound on an issue, then the meeting leader should take a note of it to discuss off-line.
Product Backlog
The product backlog is a list of all of the features necessary to create the overall product. Each feature is broken up into pieces that can be worked on by a person or a small group of people.
This is different from a list of requirements, as it is a high level and simple description of what needs to be done, such as ‘client database’, ‘login screen’ or ‘web service interface’.
Product Backlogs are often listed on a whiteboard or in a simple document that is accessible by the whole team. Wherever it is, backlog items will need to be moved around, assigned to sprints, and added to or removed from the project.
Pros –
Laying out the Product Backlog gives the team and the stakeholders a clear understanding of what work needs to be done on the project. This will help you all understand the scope of the effort, more accurately manage resources, and organize which backlog items need to precede or follow other development efforts.
The backlog is also used to identify which items are ‘necessary’ versus ‘nice to have’. The backlog also allows development efforts to be moved around to accommodate changing project needs, timelines, and developer availability. This is one of the major aspects that defines Agile: tasks can be moved and adjusted to accommodate change.
The backlog also facilitates assigning pieces of development to each member of your team to assure that everyone has work to do, and no one person has a disproportionate piece of the pie.
Pitfalls –
The flexibility to move items around, and add/change/remove tasks from the Backlog is what makes it agile. Therefore, it is important to avoid over-scheduling or overly detailed project planning of the development effort, since this can hinder the flexible aspect of the Backlog.
Another behavior to look out for is adding tasks to the Backlog on a whim, without removing anything else or adjusting the scope of the project, ie. “This is a small task, I’ll just add it here at the end.” Those “small” tasks add up!
Insight –
The Backlog (and, if you use them, User Stories) are not meant to replace requirements documentation. The Backlog is an extension of the requirements, not a replacement for actual documentation. Manage scope creep by not adding anything to the Backlog that you wouldn’t formally add to the requirements documentation.
Development Sprints
Development Sprints are specified blocks of time and work used to break down a larger development effort into more manageable and understandable pieces. A Sprint will have specific tasks and goals identified at the beginning. Sprints work great with Product Backlogs.
Pro –
Sprints are designed so that the development planning is flexible, adaptable, and manageable. If project work gets added, adjusted, or removed, then future Sprints can be adjusted to accommodate the new scope.
Breaking the development effort into defined pieces allows the team members and stakeholders to see specific progress as each Sprint is completed.
Additionally, and importantly, the stakeholders can spot-check that the work being completed matches their needs and intent, and can course-correct mid-project if needed. This is a huge improvement over discovering many issues in a completed product at the end of a single, long development cycle.
Pitfalls –
Taking a ‘waterfall’ project plan and slicing it into sprints is not Sprint Planning. Sprints are planned as stand-alone development cycles, even though they are part of the broader project.
Additionally, Sprints are free-form within the Sprint Timebox where developers can work in the order they see fit to complete their tasks. Over-planning at Sprint (say, by attaching too many dependencies to tasks within the Sprint) can defeat the flexibility and adaptability of the Sprint.
Last but not least, beware of adding tasks to a Sprint without appropriately adjusting the Sprint goal and scope.
Insight –
Plan Development Sprints in advance, each Sprint should have a goal and can even have a theme.
Tasks in the Sprints can be moved around and adjusted, but there are limits! Don’t change the purpose of a sprint mid-flight. Don’t add tasks into a Sprint without moving around or removing other tasks. Sprints are finite blocks of time for a reason: they are meant to add boundaries to the work effort.
Will this really work?
If you talk to an Agile guru, they will tell you that Agile is a mindset that must be embraced company-wide. This is true when switching over a whole company’s methodology, however, that doesn’t mean these aspects of Agile can’t be applied on their own in your projects! If the intent of the a la carte pieces is understood, and the pitfalls addressed, then each of these elements can be put to good use in your work environment.
Then, if you like one and it works well for your project, pick another off the a la carte menu and see if that works as well. Who knows, after a while you might be on your way to becoming agile without even realizing it!
About Anexinet
Anexinet is a leading professional consulting and services company, providing a broad range of services and solutions around digital disruption, analytics (and big data), and hybrid and private cloud strategies. Anexinet brings insight into how technology will impact how business decisions will be made and how our clients interact with their customers in the future.
Aaron Schantz, [email protected]
Share on 
