At the end of the day, I help software teams be agile. But that's a pretty big task, and if you'd like to get a better feel for how I do it, take a look at some of my offerings :
Agile/Scrum Enablement deliver it when you said you would
Since 2000, I have been coaching teams through their transition to agile. I've worked with teams as small as 10 people, and as big as 70. Moving to agile is hard, and it's good to have an experienced hand around.
There are different models I've followed for adopting agile, and every organization is different. In your organization this might look like :
- Doing an initial process evaluation & recommendation session optionally followed by bi-weekly visits to assess improvement
- Leading training sessions for project management, developers, and testers
- Being on-site 1/2 time for a couple months
- Being on-site fulltime for a couple weeks followed by occasional visits for the rest of your team's release
- Collaborating with other local coaches to bring agile to larger teams in parallel
- Leading a requirements discovery workshop followed by some of the above
Some of these approaches fit certain organizations better than others. How self directed is your organization? How does it respond to change? How big of a budget do you have for this training? Is moving to agile an officially sanctioned decision, or is the goal to make a couple changes to the process and produce some feedback for management to inspect?
I am an experienced XP Coach and a Certified Scrum Master.
Requirements Discovery Workshops build the right product
One of the hardest things to do in an agile project or any project for that matter is to begin. Lots of questions need to be answered. How much will it cost? Is this project technically feasible? What does done look like? What's in the backlog? Even should we do this project?
Agile teams struggle with these questions, often not answering them until halfway through the project or even after the project has completed. A requirements discovery workshop strives to answer all of these questions in a collaborative, iterative way. With the right people in the room, a week or even a few days are often enough time to generate a prioritized, estimated backlog, a prioritized list of goals, risks, and even some rough wireframes for a 3 month release.
This is no small feat, and it is only with a high degree of facilitation and relying heavily on the workshop's participants and techniques like Story Mapping, Innovation Games, and Paper Prototyping that we as a team can produce these deliverables on such a short timeframe.
Retrospectives adopt a culture of innovation
Retrospectives are a way to reflect over the past as a team. They provide a ceremony for identifying areas to improve and for celebrating successes. Run a retrospective at the end of an iteration, at the end of a release, or as a project concludes. They help us get smarter.
Companies often bring me in to introduce this practice or reinvigorate it. It is also sometimes helpful to have a neutral 3rd party run a particularly sensitive or important retrospective.
Developer Training / Coaching make it all fun
There are many practices that agile introduces that take a bit of knowledge and work to get just right. You might bring me in to help you with :
Test Driven Development - which may include
- Unit Testing
- Acceptance Testing
- Test Automation
- Pair Programming
- Continuous Integration