Blogs | FUJITSU Macroscope When is it Not Agile - Part One When is it “not Agile” – and Why Do We Care? Agile Pills copy

I was working with a Fujitsu/client project team recently as they were refining their approach to developing a replacement application. My role was to help everybody appreciate what was available in Macroscope that might be useful to them, especially regarding some of the bigger challenges in this particular project.

Tue, 9 Feb 2016 04:12:07 -0500
When is it Not Agile - Part Two Just what is “Agile”

There have of course been many great successes from taking a “big A” approach. The “sweet spot” scenarios involve the need for innovation and rapid creativity, where at the start there is an incomplete vision of the end product. (There have been failures too, but we won’t talk about those here.)

Now the astute Agile practitioner will have caught my deliberate error above. There is no such thing as a “by-the-book big A” approach. There are many books! When one reads about analysis of Agile use, it is usually in the form of “which of these .. are people using?”. Different people are using different aspects of Agile. And sometimes there are great debates between thought leaders about the superiority of some aspects over others – but somehow “it’s all Agile”.

Tue, 9 Feb 2016 04:04:45 -0500
When is it Not Agile - Part Three A Bit More Background

To illustrate, let me tell a bit more about the circumstances of the project mentioned above.

  • This was to be a replacement system. All the existing functionality had to be preserved in the first release. There was to be innovation to enable easier extensibility, but this was mostly “under the covers”. (Later releases would add new functionality.)
  • There were to be some changes to the user interface, but these were being developed by a completely separate team, using traditional techniques of mock-ups, focus groups etc. The development team was to implement this predetermined user interface with perhaps only minor adjustments.
  • There were many non-negotiable and well documented business rules to be implemented. High product quality was essential.
  • The client wanted to see reduced costs of maintenance and enhancement going forward.
  • The client required a very firm estimate for this pre-specified functionality.

So this still left lots of room for agility. We would be prototyping iteratively all the time and we would have co-located subject matter experts to help us validate and refine important details. And we would be developing with small incremental sub-releases, with continuous integration – we would be applying all of the principles and techniques of Agile that would work within their project realities. And we would ignore those aspects of Agile that would lead to failure.

Tue, 9 Feb 2016 04:01:12 -0500
Macroscope and Scrum - Part One Scrum Smaller

We are still learning. Every now and then, somebody publishes a new set of theories or a new set of techniques which attract us. Sometimes these new things become wildly popular. But the problem is that some people take a “silver bullet” attitude – and believe the latest thing to be a prescription for all our challenges and dismiss everything else we’ve ever learned.

Thu, 17 Dec 2015 02:56:12 -0500
Macroscope and Scrum - Part Two Highlights of Scrum for Me - Techniques

User Stories

To me, one of the most powerful contributions of Agile and Scrum to our profession is the focus on the User Story (along with the Use Case). The simple statement, “As a ___ I want to ___ so that ___” gives us an intuitive yet fairly precise view of the business capability that is needed and its justification. It’s easy and it’s natural.

Thu, 17 Dec 2015 02:43:44 -0500
Macroscope and Scrum - Part Three Limitations of Scrum

The Scrum Guide makes it very clear that Scrum is a process framework to manage product development, but it is not a process or technique for building products. The comments below elaborate on some outside-of-Scrum aspects that can be necessary for a successful system delivery and implementation, with some references to where these are addressed in Macroscope.

Thu, 17 Dec 2015 02:42:35 -0500
Macroscope and Scrum - Part Four Reality Checks

Not Everybody Fits the Scrum Profile

The vision of the Scrum Developer is of a flexible, highly collaborative person who is keenly interested in seeing all aspects of the product. He/she is multi-disciplinary and interested in expanding their knowledge of new disciplines.

Not everybody fits that profile. If an organization seriously wants to take the Scrum approach for all its initiatives, it has the choice of investing in extra coaching and mentoring effort to help people adjust, or getting rid of those who don’t fit the pattern.

Thu, 17 Dec 2015 02:41:23 -0500
Can we stop using the word Artifact? Artifact

I fully appreciate that language is always evolving, and as we make up new words and definitions they become added to the dictionary.

But there is one term that has become fashionable in the world of software engineering that really troubles me – “artifact”. To me it gives completely the wrong idea.

Tue, 31 Mar 2015 12:25:00 -0400
Can we Banish the word Waterfall? Waterfall


When systems people talk about “waterfall” approaches, they mean something like the picture above.

But “Waterfall” is an ancient myth!

It is a myth especially perpetuated by people who want to promote some other school of thought with a catchy name. (“If it’s not strictly _____ it’s therefore Waterfall – and we all know that’s evil!”.)

Sun, 22 Mar 2015 04:33:29 -0400
That's not a Business Case, Part 1 “That’s not a Business Case!”


The Need

I was recently asked to help with a business case for a course. It was a “soft skills” course that would contribute to team building, collaboration, creativity and productivity. The client knew instinctively that the course was important to the development and performance of her people, but she had to convince her boss that they should spend the money now instead of next year.

Wed, 11 Mar 2015 02:45:51 -0400