Doing 2 week sprints doesn't make your team Agile. Here are a few thing you might want to consider having in place as you set out on your Agile journey:
Create / Work from a backlog
The first step to solving a problem is to identify what the problem is. Creating a backlog is a great way of thinking through the first iteration of a solution. If you already have a backlog and aren't really using it, I recommend taking some time to groom it so it becomes a valuable resource.
You don't need to wait until you have hundreds of items prioritized correctly in the backlog. I recommend having just enough stories to get started, or just enough for the first minimum viable product.
When grooming the backlog, consider rewriting some possibly poorly written user stories. We slice a birthday cake vertically, not horizontally. Similar to that, I recommend have your stories span all the layers of your application. I do not recommend having 'create the UI' (that does nothing) as your first solution. Instead, try to find ways to build a shippable and usable product.
Get your roles correct
You don't need to wait until you have hundreds of items prioritized correctly in the backlog. I recommend having just enough stories to get started, or just enough for the first minimum viable product.
When grooming the backlog, consider rewriting some possibly poorly written user stories. We slice a birthday cake vertically, not horizontally. Similar to that, I recommend have your stories span all the layers of your application. I do not recommend having 'create the UI' (that does nothing) as your first solution. Instead, try to find ways to build a shippable and usable product.
Get your roles correct
Although development leads, test leads, project managers, team leads, system architects, development managers may seem like good fits for various Scrum roles, it may not always be the right thing to do.
I have seen teams where a single person worked as the Scrum Master and the Product Owner. I have seen a team where a relatively non-technical Project Manager was asked to be the Product Owner - creating and grooming the backlog of highly technical work items.
I recommend taking a little bit of time to think about the roles and get them right.
I have seen teams where a single person worked as the Scrum Master and the Product Owner. I have seen a team where a relatively non-technical Project Manager was asked to be the Product Owner - creating and grooming the backlog of highly technical work items.
I recommend taking a little bit of time to think about the roles and get them right.
Start your team on a path of self organization
Self organizing teams stick together through tough times and hold each other accountable for quality. There are some things you can do to nudge your team on a path of self-organization.
a. Allow failures
If / when the team fails to meet their commitments for a sprint or fails to deliver good product quality, you can use that opportunity to drive conversations so that the team starts holding itself accountable.
b. Get the team to commit
Self organizing teams stick together through tough times and hold each other accountable for quality. There are some things you can do to nudge your team on a path of self-organization.
a. Allow failures
If / when the team fails to meet their commitments for a sprint or fails to deliver good product quality, you can use that opportunity to drive conversations so that the team starts holding itself accountable.
b. Get the team to commit
Drive the commitments by team-input rather than coercion or deadlines. You are more likely to get frequent successes when sprint and release commitments are driven freely by the team.
c. Data driven retrospectives
I recommend collecting good data and having the team reflect on that data in retrospectives. This helps identify problems about why the team didn't meet their commitments.
Start thinking about improvement opportunities
c. Data driven retrospectives
I recommend collecting good data and having the team reflect on that data in retrospectives. This helps identify problems about why the team didn't meet their commitments.
Start thinking about improvement opportunities
When teams start Scrum / Agile, the first few sprints are usually bumpy. I recommend that Scrum Masters to maintain a list of items that are good candidates for improvements. Some of them may be:
a. Quality of User stories, Backlog Grooming process
a. Quality of User stories, Backlog Grooming process
b. Team practices - e.g. code reviews, pair programming
c. Team processes - e.g. "JIRA workflow", quality of retrospectives
d. Delivery cycles - e.g. thinking about how to establish a release cadence
I find that Scrum seems relatively easy in theory, but can be hard for teams to implement. Taking the right steps initially can help create a culture that support Scrum / Agile and can set you up for success.
I find that Scrum seems relatively easy in theory, but can be hard for teams to implement. Taking the right steps initially can help create a culture that support Scrum / Agile and can set you up for success.
| Rate this post! |
☆
|
☆
|
☆
|
☆
|
☆
|
No comments:
Post a Comment