Disciplined Agile

Photo credit: Umanix

----

Disciplined Agile (DA) has always recognized that some teams work remotely and now, given the need to respond to the challenges presented by COVID-19, we are applying our own advice with our DA training offerings.  

Starting in early March we reworked our instructor-led training (ILT) offerings so that they can be delivered remotely by qualified instructors. In the picture above we see two Certified Disciplined Agile Instructors (CDAIs) from Umanix delivering the a Disciplined Agile workshop virtually.  As you might expect, the instructors are using video conferencing software to work through the courseware with the students, but there's much more to it.

The DA workshops have many hands-on exercises, both games and case study work, in which students collaborate to learn critical concepts and techniques.  In the bottom left-hand corner you see an exercise in which a group of students are in a breakout room and are working together.  In the face-to-face (F2F) version of this exercise students move cards around on a table and discuss their decisions as they go.  In the virtual version they move images around on the screen.  In both cases the instructor is observing and helping the students where necessary.  Once the group work is over the students then do a "wall walk" by going into each of the breakout rooms to see and discuss how other groups approached the problem.

We've been very lucky in that one of our DA Training Partners has been delivering DA training to globally dispersed teams for years.  They agreed to take the lead and share their experiences and techniques with our other training partners so that we can successfully bring DA training to you remotely.  In short, we've been in a position to apply proven remote training strategies so that your learning experience is the best that it can be.

Don't worry, DA Training Partners will still be offering face-to-face training once it becomes safe to do so again.  And we'll also continue with virtual workshops as well, because my gut tells me that we're going to have a lot more distributed Disciplined Agile teams in the future.

-----

Please visit Disciplined Agile Training to discover our current workshop offerings.

While face-to-face (F2F) collaborative work is often preferred, many of us now find ourselves in a situation where that may not be an option for the foreseeable future.  Recently many organizations have asked their staff to work from home whenever possible.  For those of us who have been working remotely for years this is business as usual, but for many of our colleagues this is a new situation.  We all need to get better at working remotely, and an important aspect of that is making teleconferencing calls effective.  So I thought I would share some tips that I've found to work well.

I've organized these tips into four sections:

1. Joining a call
2. During a call
3. Organizing your environment
4. Planning and facilitating a call

Joining A Call

The best calls are the ones that start well, and an important aspect of this is people joining the call well.  Here's what you can do:

1. Join on time. When you are late for a call either making everyone else on that call wait for you or you interrupt the conversation when you do join.     
2. Announce yourself to a small group. When your call is with a handful of people, and when you're on time to the call, then it's polite to join with a simple "Hi, Scott's here" or something similar. 
3. Don't announce yourself to a large group. If the number of people on a call is large, and the limit for "large" in this case is likely 7 or 8 people, then announcing yourself as you join becomes an annoyance.
4. Join on mute. We all hate it when someone is on a call and their background noise drowns out the conversation.  An important aspect of avoiding this is to join a call on mute so that you don't disrupt what is currently in progress. Once you're on the call, verify that you're muted. We've all seen people mistakenly think they're muted when they're not, so let's learn from that and start building habits to avoid these embarrassments.  
5. Join with video turned on. We'd really like to see you!  A lot of information during a conversation is communicated visually, so bandwidth permitting it's preferable to have everyone turn their video on. You'll find that doing so will make your calls more interesting and valuable.

During a Call

It's the responsibility of everyone on a call, not just the person facilitating, to ensure that the call runs smoothly. Here are a few ways you can do that:

1. Remain in the moment. I know it's hard, particularly if you spend a lot of time on calls, to remain focused on the current conversation.  We're all tempted to check email or multi-task in some other way to alleviate the boredom.  Then suddenly we realize we missed something important and either need to let it go or ask to have the information repeated to us.  
2. Remain muted if you're not speaking. Sound quality is a critical success factor for calls.  Although it takes a bit of effort to turn the microphone on and off it can make a huge difference for the overall sound quality.  A nice side effect of this habit is that it helps all of us to remain in the moment.
3. Dress like you're at work, because you are. We dress differently at home than we do when we go into the office. Although we're working from home and want to dress down we need to remember we're still working so should dress accordingly.  Yes, it's ok to loosen up a bit on your personal dress code when doing so, but recognize that there are limits.  My advice is to dress as if it's a "casual clothes" day at your office.  
4. Go on mute.  I really can't say this enough.
5. Introduce yourself when you talk. When you're on a call with people whom you infrequently work it can be useful to start with "It's Scott, I was thinking..." so that people can learn who you are.  Although most video conference software will indicate who's talking at any given moment you may have some people on the call who don't have a video feed, perhaps because they dialled in with a phone.
6. Look into the camera when you speak. If this was a face-to-face (F2F) conversation you would very likely look people in the eyes when you're speaking.  The teleconferencing equivalent of this is to look into the camera.  This is harder than it sounds because it can be very tempting to look at yourself in the window showing your camera feed.
7. Speak up.  We would really like to hear you.  An interesting side effect of looking into the camera when you're speaking is that you're very likely aligned so that your microphone can pick up what you're saying.
8. Speak slowly.  We often find ourselves on calls with people who have different accents and who may not be fully proficient with English yet.  If you find yourself in this situation people will appreciate you making the effort to be understood by them.
9. Did you remember to go on mute after speaking?  I keep repeating this point because it's an important habit to adopt.  
10. Remember that others want to collaborate too. We want everyone on the call to participate where they can, which means we all need to recognize that we need to share the air time with others. 
11. Be flexible. Many of us have kids, pets, and other family members who may choose to barge in during the middle of a call. It happens, and frankly can lighten up the mood in many cases. On that same note, none of us are perfect.  Sometimes we're late, sometimes we forget to go on mute (have I mentioned how important sound quality is?), sometimes we may not be perfectly groomed, and so on.

Organizing Your Environment

Think about the last time you were on a call, and you were looking at other people over the video feed.  You were probably assessing how they were groomed, how they were dressed, and what the state was of their work area is.

1. Be aware of what's in the background. This can be hard to control, but do your best to tidy things up. 
2. Point your camera directly towards you. This will make it easy for you to look directly into the camera when you're speaking and very likely present you in the most flattering light possible.
3. Consider getting a headset. Although they can be uncomfortable at first, headsets can both improve the quality of the sound that you transmit and if you have noise-cancelling headphones easier for you to hear.  
4. Be in a well-lit space. We've all seen people who look like they're working in a dungeon and that's mostly because of poor lighting.   Natural lighting is best if you can do it, and the easiest way to achieve that is to set up either near or better yet facing a window.  Otherwise you may need to arrange light sources so that they project towards you. 
5. Test your equipment before the call. If you're new to teleconferencing, or you've changed your setup, you might want to consider doing a quick one-on-one call with someone to test if everything is configured correctly.  We don't want to force people to wait while we adjust our setup to get it working.  
6. Familiarize yourself with the software. There are many teleconferencing packages available to us and they all work differently.  If the software is new to you, or if you haven't used it lately, watching a quick training video is likely a good idea.
7. Be aware of the ambient noise. We've all been on calls where someone is dialing in from their car, from the airport, or from their local coffee shop.  The ambient noise is often worse than they think and it can be very distracting.  So you if you can't avoid calling in from a noisy environment then, you guessed it, go on mute as often as you can.  

Planning and Facilitating a Call

Nobody likes wasting their time on a call where nothing is accomplished.  Effective planning and good facilitation can go a long way to making a videoconferencing call successful.  

1. Have an agenda.  People need to know why you are having the call so that they know what is expected of them.  Perhaps more importantly, they also want to determine whether they need to be on the call at all.
2. Keep the attendee list short. Although this can be hard, I always try to identify who is required to attend, likely because they are actively involved in the topic of the call, and who is optional because they may need to listen in to be aware of what we're doing. 
3. Prompt people to participate.  Some people are shy, particularly when they are new to videoconferencing.  So keep an eye out for this and occasionally ask someone who hasn't spoken lately if they have anything to add.
4. Schedule time between calls. A courteous practice is to have a 5 minute "bio break" between calls.  The easiest way to do that is to adopt the practice of ending calls at :25 or :55 rather than at the bottom or top of the hour respectively.  
5. Start on time. When I'm hosting a call I will typically start the software a couple of minutes before the call is scheduled to begin so that we can start immediately on time.  
6. End on time. Many of the people on the current call may have something else scheduled, perhaps another call, immediately after this one.

One last bonus tip: You are welcome to copy the image at the top of this article and use it as a quick reminder list of the key tips in this article.  Print it and tape it to the side of your monitor if you like!

Please feel free to share this article with others or print it out so that you can keep it handy.  We’ve also put together a short tip sheet that you can tape to your monitor.

I would love to hear about any other tips you would have so that I can update this blog and share them with others.  Thanks in advance!

Since Disciplined Agile (DA) joined the PMI family in August 2019 we've gotten a collection of questions from people along the lines of "Why is there a difference between the advice in DA and PMI's advice?"  So I thought I would write a few blogs examining why that is.  This is the first.

There are several reasons why there are differences between existing DA and existing (non-DA) PMI materials:

1. They were created by different groups of people.  It's natural to get different takes on a topic from different groups of people.   
2. DA took on a broader scope than PMI traditionally has (until now). PMI has focused on project management and critical topics surrounding it such as program management, portfolio management, and governance (amongst others).  That is the scope that PMI chose to focus on and has frankly done a very good job at doing so.  The scope of DA, on the other hand, has been to address how to take an agile/lean approach to all aspects of an organization, including but not limited to management.  This is a much broader scope than what PMI has taken on, until now. As a result DA addresses marketing, finance, enterprise architecture, operations, governance, software development, and many other process areas that are important to modern organizations.  Why is this broader scope important to PMI?  Because all of these areas need to be managed/led and governed.  I believe there's an interesting implication there. ;-)
3. PMI has traditionally gone very deep into management and the governance of management activities.  I'll let the great material in our standards and practice guides speak for itself. As Stan Lee was prone to say, 'Nuff said.
4. DA has traditionally taken a more holistic view.  DA includes both what is being managed as well as the management/leadership of it.  For example, consider The Standard for Program Management Fourth Edition.  Where the existing PMI standard does a fantastic job of addressing the management aspects of a traditional program it doesn't go into critical "doing aspects" of programs such as how to address architecture, requirements, and quality activities (it does address planning and management though) for example.  This isn't meant to be a criticism of the standard but merely an observation - When we (PMI) developed the standard our focus, and once again rightfully so, was on management and governance.  It was not on the overall, holistic view of what occurs with a program.  With DA we choose to take a more holistic view, as do agile frameworks such as SAFe^R and LeSS amongst others, and go beyond management and governance.  

My point is that there are very good reasons for the differences between what is in DA and what PMI has traditionally focused on.  These differences are an important aspect of the value proposition of DA for PMI, and more importantly for our membership, because we can learn from these differences and then improve and grow based on those learnings.  We're currently evolving DA based on the great material encompassed by the existing PMI standards and practice guides and our hope is that the existing PMI offerings will evolve to reflect Disciplined Agile ways of working (WoW) too.  

In the next blog in this series I will do a deep dive into the differences between DA's take on Program Management and the PMI Program Management Standard.  I suspect this will help to make some of the ideas in this blog more concrete and it will certainly make the opportunity before us a bit more explicit.

Kurt Cagle recently wrote an article for Forbes, entitled The End of Agile. Although Forbes’ regular Steve Denning responded effectively a few days later with Why Agile’s Future is Bright, I’d like to chime in with several thoughts beyond what Steve has offered.  Here they are:

1. Look beyond Scrum. Kurt started out with a tongue-in-cheek description of an agile team, but it was really a description of a small team at the very beginnings of learning Scrum.  This is the classic “Scrum = Agile” mistake that many people make, and it plays well to people who only have a passing understanding of how agile works in practice. We recommend that you look at teams that are succeeding with agile, rather than teams that are clearly struggling.  Better yet, let’s help the teams who are struggling — rather than making fun of them.
2. Beware of agile purists. Kurt’s observation that agile has become a religion wasn’t far off.  It might be more accurate to say that there are Agile purists out there, people who often prove to only have experience with applying agile in straightforward situations — rather than in the enterprise situations that Kurt describes.  But there are also pragmatists out there in the Agile space (pragmatism is one of the seven Disciplined Agile principles) who are actively addressing how to apply agile and lean strategies in less-than-ideal situations.  We have always recommended that you be open-minded and pragmatic, to do the best you can in the situation that you face and always strive to learn and improve.
3. Agile works in a very wide range of situations.There is ample research data and case studies showing that agile works in a wide range of situations.  For example, in our 2016 Agility at Scale survey we found that organizations were in fact applying agile on large teams, in complex domains, using legacy technologies (including legacy data sources), in regulatory environments, and multi-organization situations including outsourcing.  And we have data from other studies going back over a decade that show that Agile strategies have been applied beyond the “small teams with straightforward problems” scenario for quite a while.  We recommend that you look around and see how agile is being applied in practice.
4. Scaling agile requires discipline. The article also states that agile doesn’t scale well to address big problems, yet many organizations are doing just that.  To be fair to Kurt, this is a common misunderstanding that is a result of the Scrum = Agile mindset because Scrum purposefully doesn’t address architecture (amongst many topics). But other agile methods do — in particular Agile Modeling and Jim Coplien’s excellent work around Lean Architecture — strategies which are explicitly part of Disciplined Agile.  In Disciplined Agile Delivery (DAD), we explicitly include initial architecture modeling early in a project via the Identify Architecture Strategy process goal, we show how to reduce architectural risk via the Prove Architecture Early process goal, and how to evolve architecture throughout Construction via the Produce a Potentially Consumable Solution process goal.  DAD teams also have someone in an explicit Architecture Owner role who is responsible for guiding the team through architecture decisions.  Furthermore, there is an explicit Enterprise Architecture process blade to support organization-level architecture issues.  Finally, DA the idea that Architecture Owners and Enterprise Architects should work closely together.  Our recommendation is to explicitly address architecture in your way of working, and this is something that Disciplined Agile provides clear, proven options for.
5. Data projects can be difficult. The same can be said of non-data projects too. When either domain complexity or technical complexity rise, or both, you need to become more disciplined in your approach to requirements and architecture modeling.  As Cagle implies, data projects often suffer from domain complexity, this is particularly true for the enterprise data systems he mentions. Similarly data projects tend to suffer from technical complexity in that they need to integrate data from many disparate sources that often use different technologies, apply different semantics, and are accessed via different strategies. Once again, the context-sensitive choice-driven strategy promoted by Disciplined Agile wins the day over the prescriptive methods and frameworks Cagle appears to be familiar with.  To confuse matters further, prescriptive frameworks such as Scrum and SAFe have virtually nothing to say about addressing data issues.  Disciplined Agile, on the other hand, encompasses proven strategies from the Agile Data method which are critical to success on data projects.  Our recommendation is to embrace the complexity that you face and to recognize that you will need to explicitly tailor your way of working (WoW) to address that complexity.
6. Agile is applicable to data projects…and may be the superior approach. I’m going to be blunt here – Kurt Cagle was completely and utterly wrong concerning the application of agile strategies to data projects.  While traditional data professionals often prefer to do extensive data modeling up front, this strategy has been shown to be ineffective in practice. What does work well is an agile data modeling strategy where high-level modeling is performed early in a project and detailed data modeling performed as needed during construction.  You can be very agile when supported by agile database practices such as database refactoring, automated database regression testing, and continuous database integration. And his claim that the focus on enterprise data is relatively new clearly doesn’t reflect the wealth of techniques around enterprise data modeling, master data management, and meta data management that the data community has been following since at least the mid-1990s. And yes, there are agile approaches to all of those practices.  As an aside, I started writing this blog in the evenings while attending the World Wide Data Vault Conference in Hannover.  Most of the presenters have discussed how they’re taking, or at least supporting agile — and often a Disciplined Agile — approaches on their data projects.
7. Many other claims the article makes are observably false. Contrary to what Kurt claims, there are many large and complex open source projects, and they clearly benefit from agile and lean strategies.  Examples of such projects include Linux (operating system), Hadoop (big data processing), MongoDB (database), Numenta (machine learning), Angular (web application framework), and Docker (software infrastructure) to name but a few.  But hey, it’s not as if any of those technologies have become mission critical for your organization.  And his discussion of games development?  Having actually consulted to several commercial game companies, I can safely say that they were all working in a very agile manner.
8. You must adapt your approach to address the context that you face. One process size does not fit all. Two of DA’s principles are Context Counts and Choice is Good – different teams in different situations will choose to work in different manners.  If you want your teams to be effective then you have to allow them — and better yet, enablethem — to choose their own way of working (WoW).
9. Adapting your approach requires skill and experience. In some ways, Kurt is right – enterprise-class problems require an enterprise-class agile approach. But he was wrong in assuming that because people were struggling to apply undisciplined agile strategies to these situations that agile didn’t work; the real problem was that they didn’t know how to make it work.  The fact is that others have figured these things out, and we’ve captured a lot of these strategies in PMI’s Disciplined Agile (DA) toolkit.

Let’s hope this is the end of undisciplined agile. But as Steve Denning points out, it certainly isn’t the end of agile.  I suggest this could be an important beginning for Disciplined Agile approaches.

Earlier today I keynoted at the World Wide Data Vault Consortium European conference in Hannover Germany.  I presented an overview of Disciplined Agile, some of the challenges that organizations are experiencing in their agile transformations, and how their teams can improve their way of working (WoW) via Guided Continuous Improvement (GCI).

Although all of the presentations were great, I was particularly enthralled with Bill Inmon’s keynote on Thursday.  As you may know Bill is the father of data warehousing and has written 59 (59!) books over his career, clearly putting me to shame.  Bill shared some of his experiences in extracting information from text-based sources and described several stories doing so.  One story focused on how his team had combined information culled from multiple text-based sources that together indicated that BP had a potential maintenance risk in their Gulf of Mexico operations.  Sadly his warning was ignored and several months later BP had a catastrophic oil rig failure on Deepwater Horizon.  Another story described how his team processed 5000 online postings from Nike customers and 5000 from Adidas customers.  Their analysis indicated that while Adidas was a “normal company,” that on the other hand Nike had quality problems with their shoes.  Although Bill contacted Nike to inform them, free of charge, of what he had discovered this advice was also ignored because Nike apparently already had consulting companies providing them with advice.  A year later Nike suffered a $2 billion market capitalization loss when Zion Williamson’s sneaker exploded in a basketball game watched by over 100 million people. Another text analysis project led him to discover that airlines are consistently not well liked by their customers, revealing that Bill doesn’t always end up with earth-shattering revelations.  Although the stories were interesting, Bill’s description of the techniques he was following and the challenges surrounding text-based data analytics were fascinating.

Data Vault 2 (DV2) is an extension to Inmon’s approach to data warehousing.  Dan Lindstedt, the creator of DV2, worked for years with Bill.  DV2 brings a lot of very practical strategies to data warehousing.  Furthermore, a few years ago DV2 adopted Disciplined Agile Delivery (DAD) for its process which was one of the reasons why I suspect I was invited to speak at the conference.

Kudos to everyone who made the conference a success.  I’m looking forward to next year.