Agile Assessments
Join the DZone community and get the full member experience.
Join For FreeAssessments come in all forms and there are many reasons why we do them. In the end, we want to know something about the ability of someone or something.
When working with a team or organization, an assessment can be introduced as a tool to assist in guiding an agile transformation and team improvement. For me as a coach, it’s an invaluable mechanism to communicate the transformation strategy and to measure progress.
I love the simple approach taken in Elizabeth Hendrickson’s “Back-of-the-Napkin Agile Assessment Checklist” but sometimes we need something more extensive in an enterprise transformation setting, at least until our organization or team has reached a more mature state of agility.
Over a series of posts, I’ll cover the why, what, when, and how of assessments and wrap it up with a post or two about how the data can be used once you’ve collected it. In this post, I’m going to talk about the Why and What of assessments.
You will see at times that I refer to ‘assessment’ and at other times ‘self-assessment’. While the two are not completely interchangeable, I usually make the slight distinction that an assessment is scored by someone evaluating another group. Even for the self-assessment though, ideally there is an experienced guide facilitating the process until a team is more familiar with agile practices and capabilities.
So why do an assessment anyway?
Let’s consider some of the reasons you might be doing an assessment with a team or an organization:
- Baseline the current level agile adoption. Eventually you may think about measuring progress but take the time to baseline your abilities right from the start.
- See how you’re tracking against your adoption or transformation goals. Help sustain and grow your support.
- Determine if you’re ready to move to the next level of practice or adoption. Be honest, critical and brave!
- Recognize what has been mastered and what you are able to do with the new skill or capability. Change is tough so remember to celebrate your wins.
- Identify the next things you’re going to work on. Help the team narrow or target their focus.
- Set the context for organizational change. Use the assessment instrument as a change management tool.
- Make or support the case for needed coaching or training. Outside help can propel your progress.
Sometimes an assessment or self-assessment may be for other reasons, such as creating a transformation roadmap or showing progress in order to secure continued funding. Even in these cases, I prefer to involve the team as much as possible so they can learn from the exercise and use the information derived from the assessment to target and make improvements.
What sorts of things do we look at in an assessment?
A team can be measured by improvement of a few practices or against more extensive measures that are part of a competency framework.
A competency framework conceivably will focus on things we do, like Stand-ups, Iteration Planning or Retrospectives. It could also focus on capabilities such as Decomposing Features or Define Clear Acceptance Criteria. Or even against concepts like Whole Team or Open Workspace. Using a known competency framework can be useful to bring a level of consistent understanding across teams in the organization. It also facilitates alignment of good metrics as you plan and measure the finer nuance of implementing a particular practice or capability.
The following section is a sample of assessment practices and capabilities along with a description for each.
Roll Up Competency Practice or Capability Description
Define the Product |
Identify Epics and Features |
Provide a clear definition of the product goals on the roadmap as feature and epic level deliverables valuable to the business. Produce visual specification around the Epic and Feature: personas, a feature flow chart, use case diagram, etc. |
Define Clear Acceptance Criteria |
Define what it takes for a product feature to be ready for use and the definition of done is clearly internalized by the team. |
|
Enterprise Alignment |
Demand Management |
Team is working from a single prioritized backlog, WIP is limited. |
Architectural Alignment |
Architecture aligned and actively involved in release planning. Architecture is actively working with teams to groom solutions |
|
Engineering |
Collective Code Ownership |
Developer can make code changes anywhere they need; developer can change code, fix bugs, refactor as necessary; few silos of knowledge. |
Continuous Integration |
Automated builds occur at every check in, tests pass locally before check in, immediate feedback when new code breaks the build. | |
Plan & Coordinate |
Eliminate & Manage Risk |
Coordinate work across teams to limit impact of both internal and external risks to the team. |
Plan & Groom the Backlog |
Have enough work groomed ahead of the team so the team can do the work. | |
Organization Enablement |
Empowered Teams |
People take ownership for their commitments and outcomes, within a defined set of organizational constraints. |
Develop Practice Competencies |
Do people have time to develop their craft? And do they put effort into it? Help the teams make appropriate decisions when applying the practices in their daily work. | |
Communication |
Whole Team |
Team sits together, co-location of business/product owner, team is asset/product based, team has identity not based on project, product or department. |
Daily Stand-Up |
Occurs daily at same time, lasts 15 minutes or less, roadblocks surface and are visible, team selects stand-up time. |
The Roll Up Competency, or category, shown in the first column will bring perspective to your competency framework when you describe it to others and when you process the results. I’ll show a few analysis/reporting samples in my follow on post ‘Using the Data’.
In my next post, I’ll talk about Rating Scales and Frequency, followed by Assessment Delivery Methods and finally, Using the Data you’ve collected, including use of the roll up categories.
This article was originally written by Sandi Keller for LeadingAgile.
Published at DZone with permission of Mike Cottmeyer, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments