Forum Replies Created
-
Posts
-
I would also suggest starting to read through the FLEX pages: http://portal.netobjectives.com/pages/flex/
FLEX is taking the place of Leanban in our thinking.Jim Trott
Faiez,
Thank you for the post. We have a couple of articles in this area that might be helpful:- A general discussion of decomposing features into stories/
- Help in choosing the formats for defining requirements/
Have a look and let me know what you think.
I still found textual requirements useful at times, like for special one-off functionality. And where constructing an underlying model for the table format was not justified by the gains from using it for multiple times from that point forward.
I’m intrigued by 3/3 however. If there’s a way to overcome the above “overhead,” then there are undoubted advantages to the table format from that point forward…
Yes. I set up a very large program to use 2-dimensional tables for about 70% of its requirements. There was a special model of reality behind the 2 dimensions (Parnas), and it worked incredibly well…facilitated massive automation, easily validated with customers, etc.
I am convinced that tables with a sound mathematical model beneath are one of the most powerful tools we have available. For the 1/2 to 2/3 of the time they work.
Related to your quote as well as to the nonscalability of systems, is this excerpt from John Gall’s “Systemantics:”
“Non-additivity theorem:
“A large system, produced by expanding the dimensions of a smaller system, does not behave like the smaller system.”
Yet another indication that things do not scale is the abysmal record of “pilot projects.” Just because something works on a small scope does not mean much about it working on a large scope. Even if the idea is that a pilot project will be duplicated across multiple other such projects to the benefit of a whole program or value stream…systems thinking tells us that building a bunch of pieces (even *good* pieces) and sticking them together tells us little about how well or even whether the whole system afterwards will work.
Rather than thinking in terms of “scaling up,” the only accurate way to think about building large working systems is finding the route to synergy. Things like Inflection Points, Lean-Startups, and sense-making all have a lot more to do with building successful systems (/organizations) than “scaling up” something little to work on something really big.
I hope we will leverage that distinctive…because it truly is a distinctive; perhaps our greatest one (besides the wealth of great thinker/doers on our team).
If it doesn’t hurt us marketing-wise, I’d love to see us make more of a point about this distinctive. As of now it is implicit in what we say about Inflection Points (primarily). Making our “discovering synergy, incrementally” distinctive an explicit message could be an exciting flare on the marketing horizon. As well as a possible flashpoint for SAI of course…
It’s pretty safe to say that “Agile at scale” is an overloaded term. I’ve heard it used to mean several things, often more than one at the same time:
- Doing Agile in a large, complex organization.
- Doing Agile in a large, complex project.
- Expanding the number of Agile teams.
- Integrating Agile teams into the rest of the value stream.
- Re-forming the value stream to work better with Agile teams.
- Standardizing the Agile formula across teams.
- Leveraging Agile to become better at innovation.
Obviously, any term with this many connotations is going to create confusion, and not just in academic conversations. In the most practical sense, people in the same organization will be working to solve different problems.
Here’s another deficiency of the concept: some of these problems are extremely prosaic, while others are vast. Doing Agile in a large, complex project isn’t easy, especially at the beginning. However, it lends itself to fairly straightforward solutions. The mutual accommodations that Agile teams and the value streams are a much different matter.
Ultimately, “Agile at scale” should aspire to address the final item on the list, getting better at innovation. (“If you’re going to take Vienna, take Vienna.”) That’s where the marriage of Lean and Agile is crucial. Agile doesn’t really provide any way of assessing whether you are getting better at innovation, in the Everett Rogers sense of the word. Agile creates the preconditions for being a better innovator, but you need some way of assessing the value created for consumers and producers of technology. You also need to apply the results of that assessment to the larger value stream, not just the team. For example, if you keep seeing problems rooted in the very definition of a product or project, the team may have very little control over that initial definition. Lean helps enormously in that situation, identifying the problems with project/product definition as sources of waste and obstacles to flow, among other bad consequences.
P.S. I have a nagging feeling that I’ve forgotten a couple of connotations of “Agile at scale.” That’s another knock on the term, if it’s hard to recall all of its potential meanings.
I suspect there are a lot of answers to this question. Part of it has to do with what level of the organization you are coaching/consulting. Consulting at the portfolio and, to a large extent, at the program level requires Business savvy and systems thinking. And the best consultants at that level have the “gravitas” that enables them to connect with executives and senior leadership. That comes with experience and by having had the burden of managing at a higher level. At the team level, there is more of a need for some good technical abilities and a strong commitment to and understanding of Lean-Agile processes.
There are skills that all good consultants must have. We have described these in these Learning Paths: Agile Coach: Basic, Agile Coach: Advanced, and Facilitation. Also, explore the Lean-Agile Coach topic page. We have listed a lot of resources to get you going.
Al Shalloway has blogged about coaching. It is worth having a look at coaching on Net Objectives.com.
Finally, you might want to investigate the Coaching Academy. This is for the community of practice of people who want to grow as transformation coaches. Start by looking at the Coaching Academy: Team Level Track.
