The Agile development approach is a hot topic and has been for a while.\u00a0 Although it is adopted in a lot of shops and well-documented, there are still some issues with it.\u00a0 The way we implement the Agile approach can defeat the purpose of a flexible model that allows a high velocity of production.\u00a0 That assumes you have enough resources to effectively do more than one thing at a time.\u00a0 However, there are some ways to adjust your scrums and sprints to get the most out of this methodology.<\/p>\n
One of the flaws I have come across is that teams treat a sprint as a short waterfall process.\u00a0 It does include all of the same steps as the waterfall approach (gather requirements, design, implement, test, deploy) but does not need to be as linear.\u00a0 For example, a waterfall approach to a sprint would be a few days for requirements, then to design, then implement for a while, then test, and end with a deployment.\u00a0 All you gained in this is reducing the scope of the requirements and what is deployed.\u00a0 I am over-simplifying a little bit.\u00a0 However, this is close enough to a lot of sprints\u00a0I have seen.<\/p>\n
The productivity problem is that you have resources during the sprint that are not used.\u00a0 Testing is not done until the end, so testers are idle at the start.\u00a0 Designers are not needed much during implementation, so they are almost unused.\u00a0 Team members do a lot of work at a high pace during their portion of the sprint and hang around the rest of the time.\u00a0 You can use that spare time for training and skills improvement (not a bad idea), but there are better uses of your resources.<\/p>\n
The goal is likely to keep all of your resources working on a steady and constant basis.\u00a0 This can be partially achieved by including everyone in every step.\u00a0 It makes sense for testers and developers to be involved in design and designers engaged in implementation, testing, and deployment.\u00a0 However, this is almost like busywork in some of those cases.\u00a0 A better approach is to overlap your sprints.\u00a0 This is easy to do with multiple teams.\u00a0 Nevertheless, it can be accomplished with a single unit as well.<\/p>\n
The effect is that you will have more than one sprint active at a time.\u00a0 Multiple teams will have this, but a single group may as well.\u00a0 With multiple units, a productive approach is to have members be a part of more than one sprint at a time.\u00a0 The implementation team will be the only group that tends to have a single sprint focus most of the time.<\/p>\n
Let’s use a two-week sprint as an example of how this works.\u00a0 Sprint A starts on week one and requirements are gathered (from the backlog).\u00a0 The implementation and testing team go over the items for the sprint and provide feedback, estimates, and ask for clarifications as needed.\u00a0 This is the first few days of the sprint (we will assume two).\u00a0 Next, we move into implementation.\u00a0 For this example, implementation is six days which leaves two for integration testing and deployment.\u00a0 That is not enough time for sufficient testing so we will have our testers running through scripts where possible as tickets are completed during this phase.<\/p>\n
The designers will be supporting the implementation phase, as needed.\u00a0 However, they will also be looking ahead to the next sprint.\u00a0 The design team can dig deep into designing for the next sprint and use this time to get feedback on design decisions as well as poll customers\/users.\u00a0 That should make it easy to keep the selection and clarification part of the next sprint go smoothly (maybe a day instead of a couple).<\/p>\n
As we move into testing, then the implementation team and designers will start work on the next sprint.\u00a0 They will be selecting and clarifying tasks while the testers test.\u00a0 As we move into deployment for Sprint One, we will also be working on implementation in Sprint Two.\u00a0 Rinse and repeat.\u00a0 The overlap of a few days will help keep designers busy and the\u00a0developers implementing.<\/p>\n
If you have two or more teams, you can overlap implementation, keep design short and assign designers to possibly several sprints at a time.\u00a0 This will also allow for more design time to be allocated to each sprint.\u00a0 That will pay off in clarity around requirements as well as reduced design related flaws.<\/p>\n
As you can see, these changes are not earth-shattering, nor are they complicated to introduce.\u00a0 Your scrum master and designers might have a little more asked of them.\u00a0 Nevertheless, the payoff is worthwhile, and they will find a rhythm with this process early on.\u00a0 It also helps avoid a roller coaster of activity that can often occur with team members when you do not find ways to keep them busy and focused throughout a sprint.\u00a0 Better yet, this is an easy change to try for a few sprints to see if it works for you and your team.<\/p>\n
I would love to hear other suggestions and feedback on how your attempts at improving your agile development velocity turn out.\u00a0 We can all learn from the successes (and failures) of others.<\/p>\n","protected":false},"excerpt":{"rendered":"
The Agile development approach is a hot topic and has been for a while.\u00a0 Although it is adopted in a lot of shops and well-documented, there are still some issues with it.\u00a0 The way we implement the Agile approach can defeat the purpose of a flexible model that allows a high velocity of production.\u00a0 That […]<\/p>\n","protected":false},"author":1,"featured_media":451,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"categories":[20],"tags":[21,14,27,34],"class_list":["post-450","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-building-software","tag-consulting","tag-design","tag-productivity","tag-software-development"],"yoast_head":"\n