A colleague of mine, Robin Dymond, posted this great video about Scrum and healthcare.gov on Youtube. It is a fantastic summary of Scrum and is well worth the 20 minutes to watch.
Thanks everyone for feedback, comments and suggestions for my new book, Agile Advice – Creating High Performance Teams In Business Organizations. It is available for purchase (only $2.99) on lulu.com (that’s where the link goes). Here is the blurb about the book:
Agile Advice is a collection of brief articles and longer essays about Agile methods and their principles and practices. Agile Advice articles come primarily from the popular AgileAdvice.com blog which has been in the top 50 of Agile blogs since its inception in 2005. The book has three never-before-seen essays including “Agile Mining at a Large Canadian Oil Sands Company”, “Crossing the Knowing-Doing Gap”, and “Becoming a Professional Software Developer”. Agile Advice also has a whole section on choosing an Agile method. The author, Mishkin Berteig, has been working with Agile methods such as Scrum, Kanban, and Extreme Programming since 1996.
Once you have read it, I would love to hear your feedback and reviews here. I will try to publish updates quarterly over the next year to make it even better! Thanks again for your support.
Agile Advice was started in 2005. In ten years, we have published over 850 articles (an average of just about 2 per week!). Here are some collections of the ten “best” articles. I hope you enjoy looking back at (or discovering for the first time!) some of the things that have made this such a great joy for me.
Ten Most Popular Agile Advice Articles
Ten Most Commented Upon Agile Advice Articles
I also want to acknowledge that there are a number of other contributors to Agile Advice besides me (Mishkin). These contributors are all experts, all have great experiences, and all are fantastic people to know. I’m grateful for their contributions since they have all made Agile Advice a better place to browse!
Five Most Frequent Contributors (of Articles, besides Mishkin)
Plans for the Future – Five Top Ideas for Series
Often in my classes, I’m asked for a clear comparison between the various traditional roles and the new roles in Scrum. Here is a high level summary of some of the key responsibilities and activities that help highlight some important differences between these four roles:
|ScrumMaster||Product Owner||Project Manager||Team Lead|
|NO||Define Business Requirements||PARTICIPATES||NO|
|NO||YES (Deliveries)||Define Milestones||NO|
|YES (process and people)||YES (business)||Risk Management||PARTICIPATES|
|Organizational Change Agent||NO||NO||NO|
|NO||Accountable for Business Results||RARELY (just costs)||NO|
Of course, there are many other ways we could compare these four roles. What would you like me to add to this list? Add a comment with a question or a suggestion and I will update the table appropriately!
In 2005 I had the privilege to participate in the first occurrence of this fantastic technique for organizing large numbers of people into Agile teams. It happened at Capital One in Richmond Virginia and my colleague of the time, Kara Silva, led this successful experiment. The problem was that the “teams” that management had set up didn’t make much sense from an Agile perspective. They were functional teams (e.g. a team of testers). But to do Agile well, they needed cross-functional, multi-skilled teams that could work well together to deliver great results each iteration. So Kara and a few other senior people got together all the staff in the department into a big room with a big whiteboard and facilitated a 3 hour meeting to sort out who would be on which team. Everyone was involved – all the people who would be on the teams were in the room. Those teams stayed together with the same membership long after that meeting.
This “team creation event” was a fantastic success for that particular department. What made it a success?
In the Real Agility Program, the team creation event is used to launch a Delivery Group. The key people at the meeting include all the potential team members as well as the three Real Agility Coaches from the business, from technology, and from process/people. Depending on the number of people involved, the team creation event can take anywhere from two hours up to a full day. Longer is not recommended. For larger Delivery Groups, we recommend that the team creation event be held off-site.
Facilitation of the team creation event is usually done by the process/people Real Agility Coach. If you wanted to use this process with other enterprise Agile frameworks such as SAFe (Scaled Agile Framework) you would have the “equivalent” person such as SAFe’s Release Train Engineer as the facilitator.
The team creation event should only be done when the business is ready to get a Delivery Group started on actual product, project or program work. If there is any significant delay between the team creation event and the launch of the Delivery Group on it’s work, then the teams can fracture and you may need to run the event again. A few days should be the maximum delay.
One client we worked with ran the team creation event but had some significant problems afterward because they weren’t really ready. In particular, they still had to make staffing changes (primarily letting go of some contractors, hiring some new full-time employees). As a result, the teams created in the team creation event were not really properly stable. This caused a great deal of disruption and even significant morale problems for some teams. It is essential that the Leadership Team be committed to keeping the team membership stable for a significant period of time after the team creation event. That includes any necessary means to encourage people who are thinking of leaving to reconsider. It also includes a commitment from leadership to respect the self-organizing choices made during the team creation event unless there is an extremely urgent problem with the results.
So, to make it systematic, here are the steps required to run a team creation event:
TEAM CREATION EVENT AGENDA
Have you experienced an event like this? Did it work? What was different from what I described?
The ultimate purpose of Product Backlog refinement is to ensure an ongoing conversation that increases transparency of the Product Backlog and therefore the Product itself – to orient everyone on the team to breaking out of their waterfall silos and focus on delivering business value, period.
On mature teams, a lot of the refinement work happens as ad hoc conversations while they are sitting around and thinking together about how to build something great because they are just motivated by that and it becomes part of their mode of operation.
The objective of the refinement work of any given Sprint (that often needs to be repeated over and over like a mantra with new, immature teams) is to ensure that the items at the top of the Backlog are transparent enough that the Development Team considers them ready to pull and get “Done” in the next Sprint. This is where the concept of the Definition of “Ready” (DoR) comes from – the Scrum Team defines the DoR and spends up to 10% of its capacity refining enough items at the top of the Backlog so that it can provide estimates (if required) and have a reasonable degree of confidence that it can deliver the items in the next Sprint.
Refinement is NOT solutioning – I think this is the big trap that a lot of teams fall into because there is a false assumption that technical solutions need to be hashed out before estimates can be made (part of the carried-over lack of trust and communication between the business and IT) – I would almost rather throw out estimates in cases where this is not improving – The Planning Game exercise, when facilitated well, lends itself more to increasing transparency rather than solutioning.
The fact that teams are telling us that they need to solution before they can estimate is also an indication of weak Agile Engineering practices such as refactoring, test-driven development and continuous integration (XP). The best refinement sessions are those in which the team is able to focus on the “what” – the business benefit results that the Product Owner really wants – rather than the “how” (solution). Strong teams emerge in an environment in which they are trusted by the business and management to find the right solution as a team. They don’t need to have it all figured out before giving an estimate because they are not afraid to give a bad estimate and fail. Also, if the team is struggling to give estimates, this is often a sign that the Product Backlog Items are too big. Most likely the team also needs to expand the Definition of “Done” to include testing against acceptance criteria within the Sprint so that they can estimate based on that criteria.
The “how” (solution) should be mapped out by the Development Team at a high level in the 2nd part of Sprint Planning (partly why the time box is bigger than they often think they need) and more detailed architecture, requirements and design work as part of the Sprint Backlog
But this level of maturity is very hard to do and it will take a while to get there, perhaps even years.
It also depends on your interpretation of “detail”, the word used in the Scrum Guide to describe what the team does in Product Backlog refinement. To me, it means understanding in more detail what the Product Owner really wants and needs. What does it mean to you?
I just finished reading a great rant about being on time by Greg Savage. It got me thinking a bit. I’ve been involved with Scrum and other Agile methods since the mid-90’s and in that time, my perspective on time has changed considerably.
I used to be the guy who was always late. And it was a completely selfish behaviour. Meetings, outings, even weddings. I just couldn’t believe how “uptight” people were about time. But gradually, over a period of about 5 years as I became more and more aware of the underlying philosophy of Agile, my perspective, and more importantly my behaviour, changed: I started being on time. For everything. Even if it meant doubling my travel time buffer. Even if it meant sleeping 3 hours instead of 8 hours. Even if it meant missing a meal or a drink or a personal to-do item.
Time is the only resource that, once spent, we can never get back.
Scrum and most other Agile methods respect this implicitly in their time-boxed iterations and meetings. But people on Agile teams often need time to adapt and change their behaviour. In many ways, timeliness (starting and finishing meetings on time) is a critical component of the Scrum value of Respect.
Timeliness is also related to our understanding of planning. The Horizon of Predictability is short in most work environments. Maybe a week or two. If you dis-respect the tkmeboxes of the Agile process, you are jeopardizing your ability to effectively use the horizon of predictability. Even the Daily Scrum, normally time boxed to 15 minutes each day, can through abuse of time, cause long-term ramifications in product development planning.
But really, I like Greg Savage’s point better than all the practical stuff: being late is rude. Period.
The voting for re-introducing the five values of Scrum into the Scrum Guide is heating up with some great discussion (debate?). One person, Charles Bradley is providing some interesting arguments about why “commitment” should not be included or even changed to a different word. I have posted a response. I strongly believe that the word “commitment” is the right word. Here’s the first paragraph of my response:
Hi Charles, although I appreciate your concerns about the word commitment, there is still huge support for adding the five values back to the Scrum Guide, including using that “bad” word. I would like to present to you an argument for the use of the word commitment by telling a story.
A long time ago I had a really good friend….
Check out all the discussion on the five values of Scrum and please comment or vote (or both!)
The Product Backlog is often described as the primary input to Scrum. The Sprint starts with Sprint Planning and Sprint Planning starts with the Product Owner and the Product Backlog. In principle, this makes perfect sense and hopefully it is enough for most teams and organizations to just start with the Product Backlog. And if you don’t have a Product Backlog, then just start without one, get some stuff done that the team thinks is important, invite some people to the Sprint Review and most likely one of those people will end up becoming the Product Owner and gradually take on the responsbilities of that role. I believe in just starting if you can. I even wrote a blog post about this a while back and I stand by it.
I have served as a Scrum Master and coach for a number of teams and I have identified some patterns that I think are worth addressing. Newly-formed teams tend to ask for (and need) a little more help than this in order to feel ready to start. And I have learned from experience that it is usually more effective for the adoption of Scrum and team development for the team to feel ready enough to just start.
The Scrum Guide recognizes the following inputs to Sprint Planning:
A newly-formed team often needs to address the following before the first Sprint:
If these are not addressed before the first Sprint, then they will likely need to be addressed during Sprint Planning, which can place a lot pressure on a new team (especially in environments where it is difficult to build shared understanding of the work).
Keep it simple. It’s an ordered list of all the features, functions, enhancements and fixes that might be needed in the end product. Get the Product Owner to blow these things out into a list. It doesn’t need to be a complete list. Just the most important things right now. A good test is to give the Product Owner 5 minutes. Whatever the Product Owner can think of in 5 minutes is important enough for the team to start working on. There are all kinds of techniques that can be used to order the Product Backlog. The simplest way is to just have the Product Owner eyeball it. If people are uncomfortable with this, then introduce the other ways. It doesn’t need to be perfect. It will get better and become refined and adapted as you go.
Multiply the number of working days in the Sprint (total days minus Sprint Planning, Sprint Review and Sprint Retrospective, rounding down) by the number of Development Team members by the average percentage team member dedication (hopefully 100%). If you have weird things going on with team member allocation (not 100%) then you may find it helpful to refer to this blog post. According to what the Scrum Guide says about Development Team size and Sprint duration, this number could theoretically be smaller (Sprint less than one week), but in most cases no less than 12 (3-member Development Team in a one-week Sprint) and no more than 207 (9-member Development Team in a one-month Sprint with 23 days – the maximum number of weekdays in a month).
This is a list of all of the activities that will go into the intended Increment of the first Sprint in order for it to be done. The team needs to know this before it can estimate the items in the Product Backlog as a team. Estimation is not a requirement of Scrum, but is often very helpful in refining the Product Backlog, tracking velocity and making projections into the future based on historical actuals.
In the first part of Sprint Planning, the team looks at the items at the top of the Product Backlog in order to determine what can be done in the Sprint and the Sprint Goal, keeping in mind that it will need to complete the items according to its Definition of “Done”. Once the team has set a Sprint Goal, it can then create a set of tasks that represent how the work will get done. All of the tasks should fulfill a specific attribute of the Definition of “Done” or be about the technical parts of the system that need to be built. The team should try to create a set of tasks each of which are a one-person day effort or less. Count the number of tasks. If the number of tasks are close to the number of days of the team’s capacity, the team can be confident that it has a decent Sprint Backlog. If not, then the the Sprint Backlog and likely the Sprint Goal will need to be adapted.
Hi Everyone. A Scrum Alliance colleague of mine mentioned that in a conversation with Jeff Sutherland (one of the authors of Scrum), Jeff suggested that the community could request and vote on a change to the Scrum Guide (the official description of Scrum) in order the add the values back to the guide. The values are normally listed as focus, commitment, courage, openness and respect. Please go and vote (and / or discuss) this on the Scrum Guides User Voice page. Voting is super easy – you just need to sign in with Facebook.
Among the great things I learned last week in London UK at the Scaled Agile Framework (SAFe) Program Consultant training is the concept of using the Weighted Shortest Job First method of prioritization for backlog items. The concept is similar to the Relative Return On Investment (RROI) that I teach in my Certified ScrumMaster and Certified Scrum Product Owner courses, but adds a bit of sophistication both in the background theory and in the actual application.
Weighted Shortest Job First is a numerical score where the larger the score, the sooner the job (feature, product backlog item) should be done. Scores therefore give a sequence to jobs. The score is based on the ratio between two estimates: the estimate of the “cost of delay” and the estimate of the “duration to complete”. The cost of delay is a more sophisticated version of business value in that it takes into account customer needs, time criticality and risk reduction or opportunity cost.
In SAFe, the WSJF is calculated at the level of the team’s backlog on user stories through estimates of effort by the team and estimates of the cost of delay that are done by the product owner in collaboration with program management and business owners. The effort estimate is considered a reasonable proxy for the measure of duration, but there is explicit acknowledgement that this may not always be a reliable relationship.
The SAFe SPC training last week taught me quite a few interesting and useful new things. In reviewing my class materials, I noticed this little acronym: ROAM. The way it is used in the SAFe training is that it is a mechanism for categorizing risks that teams identify as they are doing release planning. ROAM stands for Resolved, Owned, Accepted, Mitigated. The members of an Agile team or Agile Release Train identify risks and collaborate to decide how to handle them. These risks are then place on a visible grid that has each of the four categories marked. In this way, the whole Agile Release Train and their various stakeholders can have an open discussion and shared understanding about the risks to the Program Increment that they are planning. Cool!
Leaders of Agile Transformations for the Enterprise need to have good sources of information, concepts and techniques that will guide and assist them. This short list of twelve books (yes, books) is what I consider critical reading for any executive, leader or enterprise change agent. Of course, there are many books that might also belong on this list, so if you have suggestions, please make them in the comments.
I want to be clear about the focus of this list: it is for leaders that need to do a deep and complete change of culture throughout their entire organization. It is not a list for people who want to do Agile pilot projects and maybe eventually lots of people will use Agile. It is about urgency and need, and about a recognition that Agile is better than not-Agile. If you aren’t in that situation, this is not the book list for you.
These books all help you to understand and work with the deeper aspects of corporate behaviour which are rooted in culture. Becoming aware of culture and learning to work with it is probably the most difficult part of any deep transformation in an organization.
This set of books gets a bit more specific: it is the “how” of managing and leading in high-change environments. These books all touch on culture in various ways, and build on the ideas in the books about culture. For leaders of an organization, there are dozens of critical, specific, management concepts that often challenge deeply held beliefs and behaviours about the role of management.
Agile at Scale
These books discuss how to get large numbers of people working together effectively. They also start to get a bit technical and definitely assume that you are working in technology or IT. However, they are focused on management, organization and process rather than the technical details of software development. I highly recommend these books even if you have a non-technical background. There will be parts where it may be a bit more difficult to follow along with some examples, but the core concepts will be easily translated into almost any type of work that requires problem-solving and creativity.
These books (including some free online books) are related to some of the key supporting ideas that are part of any good enterprise Agile transformation.
The Scrum Guide – Ken Schwaber, Jeff Sutherland, et. al.
The OpenAgile Primer – Mishkin Berteig, et. al.
Priming Kanban – Jesper Boeg
I want to give some perspective on SAFe and the training that I have been attending these last few days. The training itself is not actually over, but we are very near the end. Just one day left, but it is dominated by the SPC exam and open Q&A on advanced topics. In other words, we have covered the essence of SAFe.
Ad Hoc, Pragmatic and Transformative
When I think about organizations or departments trying to become Agile enterprises, I generally categorize those efforts into three approaches.
The “Ad Hoc” approach is typified by a grassroots movement or an executive decreeing “be Agile” with no one really knowing what that means. A lot of organizations have some teams in this condition – they try Scrum, try some other Agile-ish things, and have modest successes. When the enterprise is large enough, these ad hoc approaches reach a natural limit of effectiveness before they become severely blocked by organizational considerations. Then, the leadership of the organization must turn to systematic approaches to becoming an Agile enterprise: the Pragmatic approaches or the Transformative approaches.
The “Pragmatic” approach acknowledges the difficulty of change, particularly for those in middle management. There is still a deep acknowledgement of the Agile values and principles, but the pragmatic part is to say that the organization will take quite a long time to adopt those values and principles end-to-end, top-to-bottom. These pragmatic approaches typically have low risk and good results. SAFe (Scaled Agile Framework) falls into this category along with DAD (Disciplined Agile Delivery) and possibly others that I’m not aware of.
The “Transformative” approach acknowledges the deep nature of Agile as a cultural transformation that can be done quickly when there is urgency to do so. There is still an acknowledgement that Agile can be difficult for many people as it requires a change in mindset and deep habitual behaviours. These approaches are transformative because they require all protagonists in the enterprise to be open to this deep and fast change to a new culture. LeSS (Large Scale Scrum) and RAP (Real Agility Program) are both systematic transformative frameworks.
SAFe, as a pragmatic approach, has a number of excellent features that will help an organization accomplish its business and technology goals.
Scaled Agile Framework – Practical, Pragmatic, and Still Pure Agile
One big concern I had about SAFe, based on other people’s comments, was that it somehow was compromising the values of the Agile Manifesto. I want to say clearly and unequivocally that SAFe is most certainly true to Agile. This fact was demonstrated multiple times and in multiple ways throughout the training:
At the same time, SAFe manages to create a relatively simple interface with a traditional management organization. This is critical and what makes it really effective as a pragmatic approach to enterprise agility. For example, at the Agile Release Train level, there are nine roles identified (e.g. System Architect, Product Management, Business Owners). The explicit acknowledgement and identification of these roles and how they interact with the SAFe ScrumXP teams through meetings, artifacts and other processes and tools helps an organization to map Agility at the staff level to traditional concepts at the middle-management level. This interfacing is also pervasive throughout the SAFe framework and occurs at all levels of effort from individual team members up to high level business leaders.
Some people have grumbled about the complicated diagram as “proof” that SAFe can’t be Agile. But a different way of looking at the diagram is that it is comfort for management. I really appreciate this. Back in 2004 and 2005 when I was consulting at Capital One on their first enterprise attempt at Agile, one of the coaches I was working with shared a story with me about the importance of comfort. The project manager for an important project was very nervous that there was no Gantt chart in Agile. At a personal level, she needed the comfort of having a Gantt chart to track the work of the team. The coach for this project told the project manager “please, make your Gantt chart – just make sure that you let the team organize themselves without being disturbed to help you with the Gantt chart.” Most Agilists are anti-Gantt. This was a real eye-opener for me. That project manager went on to gain confidence in the Agile team and was able to eventually discard the Gantt chart.
SAFe isn’t just a framework, it’s actually a scaffolding. When you build an arch, you need a scaffold to keep everything in place until the keystone is in place. In creating an Agile enterprise, you use SAFe as a scaffold to get you to Agility.
Lean, Agile and Leadership
This training has also spent a lot of time discussing Lean thinking, Lean product flow and Lean leadership. SAFe asserts four principles of Agile Leadership:
I like this list. I might change the wording slightly, but in going through the details of what these mean, it is clear that if leaders could adopt these principles, every organization would be a much better place to work.
There is a fair amount of time spent on helping leaders make the shift in thinking from traditional “scientific management” to “Agile leadership”. There are a lot of good reading references given in these discussions including “Five Dysfunctions of a Team”. There is also a lot of time spent on value stream thinking including some great discussion exercises.
Organizational Structure in SAFe
SAFe does not define all the structures throughout the whole organization. By design, it is not end-to-end, top-to-bottom. It does define a structure for three levels of activity: the team level, the program level and the portfolio level.
At the team level, SAFe relies on a slightly modified version of Scrum and Extreme Programming (XP) that it calls SAFe ScrumXP. As a Certified Scrum Trainer, I’m confident that the Scrum described is “good enough” to be legitimate Scrum even if there are small variations. One example is in the idea of commitment. Scrum espouses the value of Commitment. In “old” versions of Scrum, the Scrum Team was required to commit to the work of the Sprint (the business scope). SAFe keeps this concept. However, if you look in the most recent version of the Scrum Guide, this concept is no longer present. One thing that I think is absolutely fantastic is that several of the XP technical practices are required practices in SAFe: Test Driven Development, Continuous Integration, Pair Programming, User Stories, Acceptance Test Automation and Refactoring. I wish that Scrum would get around to officially requiring these practices. This set of canned answers is sometimes an irritant for Scrum folks, but the fact is that, again, middle managers are often made more comfortable by being provided with concrete answers. And, in my not-so-humble opinion, SAFe is providing the right answers. Since all this is at the Team level, middle managers are even more comfortable because they can tell all these staff-level people how to work.
At the program level, SAFe scales the basic concept of a Sprint up to a larger “Program Increment” (PI) concept. The core concept that holds the program level together is the Agile Release Train which is based on a limit to the number of people who can work effectively in a social network (Dunbar’s number ? 150). Again, SAFe is quite definitive about process at this level: Sprints are 2 weeks long and PIs are 5 Sprints long (10 weeks). Timeboxing is explained effectively with the concepts of cadence and synchronization as a way to ensure predictability at the program level. Unlike the simplicity of the Team level, the Program level in SAFe introduces a number of important connectors to transitional organizations. This is done through defining several roles that have extremely close analogues to traditional roles (and even use a lot of the same names), and through other artifacts such as vision, roadmap, non-functional requirements, and features. There are even a number of recommended metrics for evaluating the performance of the program (not the people).
At the Portfolio level, SAFe simplifies again somewhat in that there are no new aspects of cadence or synchronization introduced, and the number of defined roles and artifacts at this level is relatively small. One important difference at this level compared to the Program and Team levels is the introduction of a Kanban approach used to feed “Program Epics” to the Agile Release Trains at the Program level. At this level, Kanban is used to drive the flow of value, but there is not as much emphasis on continuous improvement here (although there is when SAFe discusses leadership). At all three levels, there is a constant emphasis on the lean concept of focusing on value rather than cost. This comes in many of the details, but may be a bit difficult for middle managers. Fortunately, the Portfolio level includes some excellent advice on working with budgets and allocating those budgets to business vs. technical needs and based on the effort required at the Program level with the Agile Release Trains. SAFe recommends revisiting budgets every six months (I believe this is meant to be every 2 Product Increments) and is the only aspect of cadence and synchronization at the Portfolio level.
I’ll admit that overall I didn’t particularly enjoy the training. I love SAFe. As a trainer myself, I’m too critical perhaps. Certainly, the training I deliver has evolved over ten years of work with lots and lots of feedback and mentorship. However, in the Agile community, the overall standard for training has improved greatly over the last 5 years and I would love to see our three trainers who helped with this course improve their delivery.
There are a also some general comments about the training that I would like to make that are about personal preference.
First, I would prefer more small exercises that are experiential. For example, there was a great deal of time spent on centralized vs. decentralized decision-making and leadership which could have been compressed greatly with a simple exercise like the “Command and Control Walking Simulation” which takes about 5 minutes to drive home the point unequivocally. The first two days were largely lecture with a couple big exercises (both the lecture and the big exercises were generally good).
Second, the slides. The slides. The slides. The slides… and more slides!!! Too much by far. And using the slides for lecture made it very difficult to stay on track for time with lots of slides missed or touched on only very briefly. This is anxiety-inducing and boredom-inducing for me. Some people like lots of slides, but most people don’t.
Third, not enough breaks for a 9 to 6 training session. Usually just one break in the morning and one in the afternoon as well as a short lunch. Two breaks and a longer lunch would have made it much more tolerable from a personal comfort level. At one point on the third day I just had to take an extra break and I ended up missing about 30 minutes before I felt ready to come back.
I’m happy I invested in this for both myself and for Travis. We have learned a lot about SAFe, a little about Agile and Lean, and we are both excited about offering SAFe-related services to some of our clients. At this point I am convinced that it is appropriate and good under some common (but not universal) conditions.
I will probably write several more articles about SAFe as I process the information and start to relate it to more specific aspects of Agile, Lean, organizations, management, leadership, productivity, and, of course, our own Agile Enterprise framework, the Real Agility Program. I’m excited and happy to see that the two frameworks are not competitive or exclusive in any significant way… more about that of course!
Lyssa Adkins, the “Agile Coaches’ Coach” has written a fantastic article sharing her feelings and perspective on SAFe. (Thanks to Gerry Kirk for bringing this article to my attention!)
As you know, dear readers, my colleague Travis and I are at SAFe Program Consultant training with Dean Leffingwell this week in London, UK. I have lots of notes even after my first day and I will write one or two articles this week giving you my impressions and highlights. I have already reviewed all the course materials including appendices, ahead of the actual training. I can say this so far: SAFe has a lot of great things in it, and overall, I think it is a fantastic example of a Pragmatic approach to Enterprise Agile Adoption. I will definitely be writing more on this idea of Ad Hoc, Pragmatic and Transformative approaches.