- Agile Training
- Agile Coaching
- Agile Metrics
- Agile Assessment
- Agile Project Inception
- Mingle Configuration
I’m an agile software development “catalyst”, helping software teams deliver value. I do agile training and coaching across a variety of disciplines, but primarily focused on project management and iteration management.
Agile XP Game 3 hours
This is an introduction to agile terms and approach using a lego construction exercise. The lego-building is done using iterations, with iteration planning, demos, and retrospectives. It is accessible to both technical and non-technical team members and helps to develop deeper relationships through “play”.
Upon completion of this class, participants will understand the fundamentals of agile projects and how it differs from classic project management.
Intro to Agile 5 hours
This is an introductory agile class at a level consumable by both non-technical and technical attendees. This is a fantastic follow-on to the XP game, as it helps to translate the agile concepts from the game into software development.
Agile Story Writing 4-8 hours
This class gets into the details of how to decompose functional requirements into “user stories”, the staple of agile requirements. Decomposition is one of the most challenging aspects of agile software development; I often refer to it as agile software development’s “secret sauce”. This is geared towards the folks who are responsible for representing the end-user to the product development team, such as product owners and business analysts, and testers. Developers, management, and other project stakeholders will also benefit from learning this critical component of agile projects.
The key to learning in this class is in the struggle to decompose requirements into independent stories that have value, can be tested, and are small enough to be implemented within an iteration.The struggle is accomplished through exercises incorporated throughout the class.
With some additional preparation prior to the class, I can incorporate actual project examples into the exercises, so that the output of the course includes user stories for actual projects.
Upon completion of this class, participants will understand the differences between work decomposition in an agile environment (e.g. story trees) from that of a classic approach to software projects (e.g. work breakdown structures).
Agile Project Management 8 hours
Managing agile projects is quite different from managing projects with a traditional approach. This course will help project managers, iterations managers, scrum masters and others to understand how agile changes the project management approach. Some questions participants will be able to answer at the end of the training:
- How do you start an agile project?
- How do you manage the PM iron triangle (scope, schedule, resources) in an agile project?
- How do you estimate effort?
- What metrics do you use and how do you use them to impart information on project status?
- How do you communicate progress to stakeholders?
- How do the responsibilities of an agile project manager differ from those of an iteration manager/scrum master?
- How do you do iteration planning ?
- How is release planning performed ?
- How does the agile manifesto concept of “responding to change over following a plan” impact planning activities?
Agile has few rules and dictated process. This does not mean no process. Teams are expected to define their process based on empirical feedback loops – that is, try something, assess whether it works, and the perhaps try something else. With the SDLC of old, the process is usually defined in a more prescribed manner. For instance – the anointed SDLC usually provides a bevy of document templates to create requirements specifications, design documents, etc.
With no specific rules, the options can be overwhelming. For instance, how does the team socialize architecture and design across the team. Is it on a wiki, or in a more formal location? When a developer comes across a coding decision that has architecture or design ramifications, how does she raise this for broader consideration and incorporation into the design/architecture?
I use several techniques in my coaching approach for agile teams. I spend a great deal of time – particularly at the outset – asking questions and listening. I prefer to help teams identify their own solutions to their issues, because the team then owns the solutions. With my diverse agile background – across industries and roles at over a dozen companies – I can share others’ experiences to help inform the team.
My coaching approach is based on “see one, do one, teach one”. For example, watch me facilitate an iteration planning meeting, then you do it next time, then – and this is often left out – you teach someone else. In order to teach someone a practice, you must understand it at a deep level. This is where the learning is cemented.
I enjoy pairing with folks as part of the coaching process. If you and I work on something together, with your hands on the keyboard, you internalize the learning more deeply than if I were to simply show you how to do something.
An initial coaching engagement can last anywhere from 2 weeks (minimum) to 8 weeks on a full time basis. After the initial engagement, I strongly recommend periodic visits to ensure the team maintains agile momentum. These subsequent visits can be in person or remote, or may just entail a regular review of project artifacts and phone calls. The follow-up approach will be determined during the course of the initial engagement.
I do agile metrics analysis, where I turn the data captured from agile project management tools into information. This is not limited to the canned graphs and dashboards that many of these tools provide, but is generated from source data itself. If your project does not have a release-level burn-up (or burn-down) showing where the team stands on its ability to deliver on its promises that is well-understood by the team and its stakeholders, you’re not alone. This is the most prominent shortcoming I see in the agile teams I have coached. The good news is that I can usually generate meaningful metrics from what you have and can define an approach to gathering the right data go gain even more insight within a couple of days.
Many teams hit walls in their agile adoption, where they need help to figure out how to improve agile practices. I have worked with many teams and have seen almost every obstacle there is. I’ve used many different techniques to help teams improve – mostly by facilitating a team’s self-identification of improvement. The key, really, is to use a scientific approach – form a hypothesis, try a new approach, and assess the results. I really enjoy helping teams find their way forward.
My approach to an assessment is to provide a framework and then coach the team in assessing itself using the framework. I can recommend actions as well, but I find that when teams self-identify the actions, they are more likely to own the work. The identified actions then form a backlog, ordered by benefit and cost, which can be addressed within the team’s existing iterations.
Agile Project Inceptions
I feel that Project inception is a critical aspect in getting a project established on the right footing for success. This may entail agile training, establishing an initial product backlog, gaining agreement on the agile practices that the team will utilize (e.g. test-driven-development) and helping a team to establish its initial norms and process. These inceptions are intense and require a significant commitment from the client to make people available.
An inception can take from one to three weeks, depending on the size of the project, the size of the team, the team’s agile experience, whether the team has worked together before, domain familiarity, technical stack familiarity and other factors. An inception usually starts with everyone together, but then can split a bit, with technical folks working on technical aspects and product owners/business analysts working on defining functional requirements.
Inceptions will be tailored for the team and will require roughly 6 hours per day from participants. The remaining 2 hours will be used to consolidate and report results and status on a daily basis.
Mingle is an agile project management tool from ThoughtWorks. It competes with products such as Rally, VersionOne, Pivotal Tracker, Jira/Greenhopper, etc. I have used many different agile project management tools in my engagements with clients and they all have shortcomings, including Mingle. So far, I have found Mingle to be the most flexible and powerful tool on the market and can be tailored to how you manage projects. The trouble with this is that Mingle’s flexibility comes at a great cost to simplicity. I have configured Mingle on many projects and understand the tool at a deep level.
If you have questions like: “When will we be done?”, or “How often do my stories get rejected by QA?”, or “How do I ensure the timestamps for status updates are accurate?”, I can help.