James Trott

Forum Replies Created

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • in reply to: FLEX and transformation #36316
    James Trott
    Keymaster

    This represents some newer thinking over older thoughts such as Leanban and Scrum.

    in reply to: Leanban for business + tech tasks #36308
    James Trott
    Keymaster

    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

    in reply to: User story focus #30074
    James Trott
    Keymaster

    Faiez,
    Thank you for the post. We have a couple of articles in this area that might be helpful:

    Have a look and let me know what you think.

    in reply to: Tables #29676
    James Trott
    Keymaster

    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…

    in reply to: Tables #29674
    James Trott
    Keymaster

    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.

    in reply to: A biologist looks at systems thinking. #28287
    James Trott
    Keymaster

    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.”

    James Trott
    Keymaster

    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…

    • This reply was modified 5 years, 11 months ago by James Trott.
    James Trott
    Keymaster

    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:

    1. Doing Agile in a large, complex organization.
    2. Doing Agile in a large, complex project.
    3. Expanding the number of Agile teams.
    4. Integrating Agile teams into the rest of the value stream.
    5. Re-forming the value stream to work better with Agile teams.
    6. Standardizing the Agile formula across teams.
    7. 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.

    in reply to: Transformation Consultant #27800
    James Trott
    Keymaster

    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.

    in reply to: Continuous Improvement with the Improvement Kata #27550
    James Trott
    Keymaster

    Jim, I haven’t used it yet. But fun that you mention it since I have been reading the Toyota Kata book by Mike Rother. I am also interested in hearing how people have applied it.

Viewing 10 posts - 1 through 10 (of 10 total)