This is the governing body for certification in Disciplined Agile.
LIVE CHAT 24 HOURS PER DAY
We just released an updated version of Evolve WoW based on the great feedback we've received. Here is a summary of the changes:
Great feedback! I will respond with greater detail on Tuesday but as you can see in Chapter 1, which we just posted, we've already acted on some of the feedback below. We're going to update and repost this goal in the next day or two, likely Tuesday given that Monday is Thanksgiving here in Canada.
If we consider the product life-cycle stages proposed by Kent Beck: Explore, Expand, Extract the overall WoW strategy will also change in time.
imo for Management level, it is important what we have to manage. Examples
In fact, we should have a Lean Exploratory Startup not only for the product, but also for the process. I have used the term Minimum Viable Process that will be born in the same time with the MVP.
The WoW will evolve at the same time as the product.
Was evaluating this goal of WOW, and was wondering if we mention a dimension around the scale of WOW or perhaps think in terms of layers/ levels in the organisation. All of these WOW elements applies to all layers/ levels/ scale in the organisation.
So perhaps think about identifying the different layers/ levels/ Scale where this could apply:
Identify Process Improvements - "Ad-hoc process improvement."
This is, in fact, a very powerful Agile tool and the Leanest (!), used for continuous improvement. As I have mentioned before, stand-alone practices cannot provide the optimum. To be effective should be combined with other practices as controlled experiments, retrospectives, and collaborative work. That means we should treat them as some kind of experiments that should be the subject of JIT and periodic retrospectives.
Kent Beck first XP team that works for CCC projects has used this technique and that allowed to shape the XP as it is now. One example was "dedicated integration computer".
My proposal is to rename as JIT process improvements and add some of the above comments. In fact, in many cases, we have dome such kind of improvements after Pair Programming, Model Storming, and opportunistic Look Ahead.
Identify Potential Improvements – “Core Agile Practices” instead of “Best practices”
There are no such things as best practiced (... where a lot of practices with such label can be very useful). We have instead a very valuable thing “Core Agile Practices” (named by DAD “critical” practices). There is a specific value of this practices. Maybe are not the best options in our current context, maybe we do not have the skills, but this is the value:
Adoption of Core Agile Practices must be opportunistic:
IMPORTANT – Core Agile Practices are already a significant part of DAD guidance but what is missing is exactly this: to explain their contribution to WoW improvement & how to use them. Imo It is the most severe missing part from DAD guidance.
Identify Potential Improvements – Local “Best practices”
Instead of industry best practices (... do not exist), we can have some “local” best practices, resulting from the experience in the local organization, product or team context. Yes, it is about “Leverage and Enhance Existing Infrastructure process goal (Chapter XX)”. To be effective, we need to be used as any other existent knowledge/experience:
Choose Collaboration Styles vs Communication style
I rather use here the title – Choose communication style. Collaboration style should rather talk about how we really collaborate (ordered):
Collaboration style is fundamental. You can asses how likely is the improvement (... and the start of improvement!) only by this aspect that will dramatically affect all the others.
Principles - Collaboration with other teams will always help
About this part <<Principles - The other teams we collaborate with are evolving.
“Very few agile teams are “whole” in practice they must collaborate with others to achieve their mission.”>>
The main problem here is that if we have only “whole” teams, collaboration it is still a must (same thing as for senior skills individuals inside a team). The real “whole” - involved in optimizations & improvements - is not the team, but the union of teams.
I propose this kind of reformulation:
Collaboration with other teams will always help. Very few agile teams are “whole” in practice – they must collaborate with others to achieve their mission. More: two “whole” teams that collaborate and share experience will get better results than working as “local” teams. The other teams are evolving their WoW over time anyway but evolving together will give an optimum result for all teams.
I'm very happy to announce that we've released the excerpt for Evolve Way of Working (formerly Improve Team Process and Environment). In many ways this captures the key thinking behind the new book.
Looking forward to hearing your feedback.
© 2013-2019 Project Management Institute, Inc.
14 Campus BoulevardNewtown Square, PA 19073-3299 USA