Hello, World!
From the Disciplined Agile Applied Blog
by Scott Ambler
This blog explores pragmatic agile and lean strategies for enterprise-class contexts.
Recent Posts
Data Technical Debt: 2022 Data Quality Survey Results
Is Technical Debt A Management Problem? Survey Says...
You Think Your Staff Wants to Go Back to the Office? Think Again.
Contracts, Procurement, Vendors, and Agile
Disciplined Agile 5.4 Released
Categories
#AgileBeyondIT,
#ChoiceIsGood,
ACP,
agile,
Agile Alliance,
agile-manifesto,
book,
Business Agility,
Certification,
Choose your WoW,
Conference,
Context,
Continuous Improvement,
contracts,
COVID-19,
Data Management,
database,
DDJ,
Disciplined Agile,
Enterprise Agile,
estimation,
Fundamentals,
Governance,
GQM,
guesstimation,
http://disciplinedagiledelivery.com/principles/be-awesome/,
India,
information technology,
Introduction,
Kanban,
lean,
MANAGEIndia,
math,
MENA,
Metrics,
mindset,
News,
OKRs,
Organization,
People Management,
Planning,
PMO,
Portfolio Management,
Principle,
Project Management,
Quality,
Ranged Estimates,
Remote Work,
Scrum,
Security,
skill,
software,
Surveys,
Technical Debt,
Technical debt,
Terminology,
Transformation,
value stream,
vendor management,
VMO
Date
I just thought I would kick off this blog with a traditional "Hello, World!" posting describing my vision. My goal is to share agile and lean strategies, concepts, and ideas for people working in enterprise-class settings. There's a lot written about agile and lean for small startup organizations, which is great, but I never get to work in those sorts of situations. I tend to work for large, establish organizations that have existing cultures, existing ways of working (WoW), and legacy systems galore. The challenging environments that most of you are working in too.
Luckily there is a wealth of material in the Disciplined Agile (DA) toolkit to draw from and it's constantly evolving. Sometimes I will write about fundamentals, my next blog posting will be a brief overview of DA, sometimes I will write about how to apply existing techniques in an agile or lean manner, and sometimes I'll write about techniques that are brand new to you.
I'd like to share my philosophies regarding process so that you have a better understanding of my overall approach:
- There are no best practices. Every practice or technique is contextual in nature. They have strengths and weaknesses, they work well in some situations and they don't work well in others. For over thirty years now I have been actively searching for a best practice and have yet to find one. I've run into a lot things marketed as "best practices" but have never found one that works well in all situations nor one that doesn't have some drawbacks to it. But I will continue looking.
- You need to experiment. Just because a strategy worked well for someone else in a similar situation to yours doesn't guarantee that it will work for you. You still need to try it in your environment, observe the effects, and then act accordingly.
- Theory is great, but experience is better. Don't get me wrong, I'm a firm believer in theory and read avidly. But I strive to see strategies applied in practice, and better yet to apply those strategies myself. I'm constantly looking for new ways of working (WoW) to share with others, but to do so usefully I want to first understand the practicalities of a given technique.
- When someone tells you something can't be done, what they're really saying is they don't know how to do it. I often run into people who say "Agile is great, but it won't in my situation." I've never actually run into a situation where agile wouldn't work, and I've been doing this for a long time in a wide range of environments. I have run into situations where a traditional (sometimes called predictive, see my next point) strategy makes more sense than an agile approach. Fair enough. Traditional strategies have their strengths and weaknesses too. Our advice is always to do the best that you can in the situation that you face, so if a traditional strategy is the best fit for your situation go for it.
- "Predictive strategies" generally aren't. This statement will likely get me into trouble, but that's arguably my natural state. The fifth value of the Disciplined Agile Manifesto is "Transparency over (false) predictability." The basic idea is that it's more important to provide transparency into what is happening and to provide realistic projections based on actuals. Yes, you'll often be asked to provide cost and schedule estimates, and even make good guesses around the scope of your effort so that senior management can make fundamental investment decisions. And there's a range of techniques to do these very things that we cover in the Disciplined Agile toolkit. But we need to remember that agile/lean operates under a different mindset than traditional. We've found that in most situations it's better to focus on investing wisely, on getting good value, rather than focusing on coming in on or under budget. We've found that in most situations it's better to focus on delivering something when it's needed and ready rather than focusing on coming in on schedule. We've found that in most situations it's far more important to allow requirements to evolve than it is to build to spec. Notice how I've used the term "in most situations" a lot? Remember, there are no best practices. So you may be in a situation where one or more of coming in on budget, coming in on time, or building to spec are actually critical. Those situations are rare in practice, assuming you're in an environment where you're allowed and able to have honest conversations about such issues, but they do occur. Discipline Agilists prefer to focus on transparency because it enables better governance and better decision making. But this is a pretty big concept which I will share in coming blog postings (and I'll back up my assertions with industry data too).
- Failing fast is fine, succeeding fast is better. There's a lot of rhetoric in the agile community about failing fast, which is clearly better than failing slowly and expensively. But we'd rather succeed fast. You can do this by leveraging the knowledge in the DA toolkit to identify techniques to experiment with that are most likely going to work in the situation that you face. This is a technique we call Guided Continuous Improvement (GCI).
- I'm still learning too. One of the things that impresses me about PMI and our membership is the wealth of knowledge and experience people have. I'm looking forward to great conversations.
- Please bring me hard problems. Given point #4, I would love to hear about situations where you think agile strategies won't work. Those are always interesting conversations for me, I hope that I'll be able to help you, and I suspect the conversation will provide great fodder for a blog posting. Let's see how it plays out!
It's going to be a fun and interesting ride. So hello world!
Posted on: September 23, 2019 01:04 PM |
Permalink
Comments (15)
Please login or join to subscribe to this item
Alexandre Costa
Scrum Master| Integer Consulting - Pictet technologies
Loures, Portugal
Very interesting , thanks for sharing your view.
Scott Ambler
Consulting Methodologist| Ambysoft Inc.
Toronto, Ontario, Canada
Welcome to the community, Scott!
You will find that there is a very diverse group of active contributors (much more than on PMI's LinkedIn discussion group) and you will likely get some really interesting feedback from practitioners outside of technology who would want to know what agility looks like in their worlds.
Hope to see you or Mark in Philadelphia at the Global Conference!
Kiron
Collins Aluga
Quantity Surveyor| MCK Contract Services Ltd
Nairobi, Nairobi, Kenya
Very interesting perspective.Thank you
Rami Kaibni
Community Champion
Senior Projects Manager | Field & Marten Associates
New Westminster, British Columbia, Canada
Great points Scott. I find that in Construction, pure Agile doesn’t work and we tend to go with a Hybrid Waterfall - Adaptive Approach.
I’d like to hear your opinion on this Scott.
Welcome to the Community.
Scott Ambler
Consulting Methodologist| Ambysoft Inc.
Toronto, Ontario, Canada
Rami, thanks!
I'll give you a typical consultant answer - It depends. It depends on the problem that you face, the culture of your organization, and the skills and experience of the people involved. So not knowing what you're trying to accomplish (building a web site, a bridge, a space station?) I can't really say what strategies would be applicable. I also know nothing of your people, or if you face regulatory compliance issues, if you're geographically distributed, and other factors.
So why am I saying this? Well, it would be good to hear more so that I can point you in the right direction and maybe get a blog out of it (yay for me). Also, I run into a lot of situations where the issue isn't that you can't take an agile approach it's just that the people involved don't know how to do so. A lot of people get hung up on agile purism and unfortunately limit their ability to work. For example, if you believe that modeling and planning up front "isn't agile", or that you can only be agile if you're working face-to-face, then those "pure views" are limiting your ability to streamline your way of working (WoW).
We also see teams in situations where they're taking a hybrid approach, as you indicate, because that's the best they can do (or be allowed to do) right now. That's great. An important philosophy of DA is that you start where you are, do the best that you can given the situation you face, and always strive to get better. DA provides the options, and the guidance to choose the options, that are currently the optimal ones for you.
So, hoping you can share a bit more about your situation.
Rami Kaibni
Community Champion
Senior Projects Manager | Field & Marten Associates
New Westminster, British Columbia, Canada
Scott,
Thanks for your response. It can be lengthly to explain to you in details what type of issues we face an why we think hybrid is the best approach but I can give ou an example:
You have a comlex construction project with 30 subcontractors involved in it and you are the project management firm. If you want to go pure Agile then:
1- You can't define any SOW for any of the subcontractors and you will count on rolling wave planning as opposed to a fixed price or cost plus contract.
2- Design-Built Projects if you want to inspect and adapt on every floor you build, you will end up with significant issues both cost and time wise because the design elements are all connected to each other and thats why buildings are normally fully designed from the outset of the project. Makes Sense ?
There is a lot more to mention and talk about, maybe I am the one who should write a blog about Agile in Construction Projects.
Scott Ambler
Consulting Methodologist| Ambysoft Inc.
Toronto, Ontario, Canada
Your assumptions seem a bit off to me.
1. Why can't you define a SoW for a subcontractor? Why do you have to count on rolling wave planning? Yes, that's an option but there are others that you could use as well, including fixed price. See the Secure Funding process goal in DA for some common options. http://disciplinedagiledelivery.com/secure-funding/
2. Sounds like Inspect and Adapt isn't the way to go. Because you have significant costs from changes (hey, move that wall over there and put an extra bathroom here) you need to invest in more up front planning. As I mentioned earlier, I'm working on an article on this very topic now as it's something that a lot of people seem to struggle with.
You should consider writing a blog about Agile in Construction projects if you've actually done that before.
Priya Patra
Delivery Director| Capgemini India Technology Services Ltd
Mumbai, India
Hey Scott, Someone asked me about Agile in Pharma, could you guide me to some resources on the same ?
Scott Ambler
Consulting Methodologist| Ambysoft Inc.
Toronto, Ontario, Canada
Priya, we have an article at http://disciplinedagiledelivery.com/regulatorycompliance/ about regulatory compliance. I did a quick google search on agile pharmaceutical development and there are a lot of resources out there.
About 10 years ago there was a presentation by an FDA auditor at the big US agile conference about the realities of agile and FDA compliance. It was really solid. It was recorded if I'm not mistaken, so you if you poking around the Agile Alliance site you may be able to find it still.
Rami Kaibni
Community Champion
Senior Projects Manager | Field & Marten Associates
New Westminster, British Columbia, Canada
Scott,
Thanks for your feedback. It is difficult to reply the overall picture via a comment that’s why my assumption might seem a bit off. I am considering writing an article about agile in construction projects soon.
I look forward to reading your upcoming article.
Scott Ambler
Consulting Methodologist| Ambysoft Inc.
Toronto, Ontario, Canada
Rami, definitely understand how it's too detailed for a reply. Looking forward to your article.
The fundamental point is that you need to be as effective as you can be in the situation that you're in. "Purist agile" that is geared for a small software development team taking on a straightforward problem isn't going to get the job done for a team in a different situation. So you need to tailor your way of working (WoW) to reflect the context that you face. So "construction team agile" is very different than "software team agile".
Rami Kaibni
Community Champion
Senior Projects Manager | Field & Marten Associates
New Westminster, British Columbia, Canada
I agree with you Scott. Stay tuned !
Al Shalloway
Founder and CEO| Success Engineering
Edmonds, Wa, United States
Scott:
thanks for this. I can see some interesting conversations we're going to have to have :) haha.
the world (and ourselves) will be better for it.
Please Login/Register to leave a comment.
|
"To you I'm an atheist; to God, I'm the Loyal Opposition."
- Woody Allen
|