Enterprise Architecture Blog Posts
Need a little more room to share your thoughts with the community? Post a blog in the SAP Enterprise Architecture group to explain the more complex topics.
cancel
Showing results for 
Search instead for 
Did you mean: 
stevang
Active Participant

patrick-perkins-ETRPjvb0KM0-unsplash.jpg

Agile can provide many benefits, but it has its pitfalls as well…

The most annoying part of Agile

Most annoying part of Agile architecture… reopening all decision, never ending alignment, too many meetings,

Are we missing the whole idea of Agile? We ideate, we decide, we prototype, we “fire it up”, and if we fail, we fail early…

So, are we missing the point of Agile?

Agile is about being fast, Agile is not about “avoiding” decisions… Yet too often we are lost in endless attempts to “please” everyone through endless alignments… Looks like an ideal place to hide from responsibility, right?

Should not be like that…

Agile Manifesto

Agile Manifesto values: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan.

Agile Manifesto 1.jpg

What does this mean?

Without going into big and bulk definitions, I will try to explain what this means in the practical terms (my view):

  • Individuals and interactions over processes and tools – we value individuals and its expertise; we do not "bound" them and “box” them to predefined processes and tools – we give them freedom to think and create.
  • Working software over comprehensive documentation – what is the purpose of software building? The purpose is to have working solution – not to produce endless documentation artifacts, who in the end, nobody is going to read or reuse.
  • Customer collaboration over contract negotiation – again, why do customers need working software? Then need it in order their problem is solved, their needs are met – we listen to customers and aim to provide working software which is solving their problem – we (and the customer) do not waste enormous time setting full & fix scope up-front (however, worth mentioning, this flexibility does have an additional cost).
  • Responding to change over following a plan – we embrace the change, no project is without changes, so why avoiding it – if changes are expected, let’s use it to improve the overall delivery and build working software our customers need (of course, this flexibility also does have an additional cost)

The concept is really very good – putting people (individuals) and gain value from their ideas (e.g. ideation in the Design thinking); providing in the incremental way the working solutions (PoC, Pilot, MVP etc.), customers & their needs a the first place (fitting the customer needs); and be prepare to change the “route plan” in order to deliver the outcome (do not be “frozen” with changes, be fast in adopting it).

But this concept tends to be misinterpreted very often…

Agile Manifesto 2.jpg

Agile does not mean (or should not mean) – no governance, no documentation, not envisioned scope (where we want to be) – and it’s not meant to be delivered without any plan…

  • Ideation is great and individual must be encouraged to step-in and bring the ideas – but we cannot afford all this is done without any processes and tools.
  • Having working solution is one think – being able to maintain it, enhance it, and reuse it is completely different dimension. We are documenting in order we can properly maintain the solution (without being locked to the developers who built it); we can build on top of in future; and above all, we can reuse it in other projects we deliver… For all that, we do need reasonable amount of functional and technical documentation – sorry to all Agile “evangelists”, but this is really needed…
  • We should not “micro-manage”, and negotiate to the last letter, the path to the final solution, but we still need to have clear alignment & understanding where do we finally want to be. Strategy is not something customer is building “on the fly”.
  • Embracing the change is okay – but this does not mean we continue working without any plan – we simple adjust and re-plan backlog items for the forthcoming Sprints…

Agile is not a synonym for the chaotical delivery – although, in Agile there is something called “cowboy coding”[1], in particular “cowboy coding” approach could not be consider as an Enterprise grade approach. Agile must have its “ceremony” as well – but general idea is not to have it too much.

Then, is it better not to be too Agile?

No, this is not about if e.g. Waterfall is better than Agile – this is overemphasized dilemma from the past. In fact, common sense would simply tell us – let's use both (or all) knowledge we can, to our advantage – let’s use the best from both… Maybe hybrid approach works best, as described in the article It’s Time to End the Battle Between Waterfall and Agile (hbr.org) by Antonio Nieto-Rodriguez

Finally, Agile also requires decision making…

Agile does not mean – no responsibility…

Teamwork – we all work together, so we all make decision together?

Yes, we do participate in the decision making, but not necessarily all of us equally contribute in making the decisions. Sorry, but in every project (or part of the project) we must have those who lead and steer the team, formal or informal leaders – and responsibility for making decisions must be on the (formal) leaders. Simple as that!

Hiding from decision making in endless discussion – this is clear misuse of Agile. People are invited to participate in discussions, to provide ideas and opinions – but decisions must be reached in a reasonable time. Once the decisions are made, we must commit on them. Please note, even in Agile, once we commit on specific work items, we do not change it during the Sprint – the time for discussion is gone. We may (and maybe should) re-discuss it on the Sprint review.

We all have to agree?

Another common misuse of Agile: “we all have to align, we all have to agree”…

No, we do not have to agree on everything, people can have their different views – but somebody still must take a decision, and assume the responsibility.

No hiding behind the group – responsibility should be individual.

Decision can be good or bad. Not making decision is always bad!

Remember, in Agile if we need to fail, let’s fail early… In contrast to this, if we do not test any concept (as no decision has been made) we fail as well, but do not learn anything from that failure

Acknowledgment

*) Intro photo by Patrick Perkins on Unsplash

**) This article uses SAP Business Technology Platform Solution Diagrams & Icons as per SAP Terms of Use  governing the use of these SAP Materials (please note, newer version of the Solution Diagrams & Icons, as well as Terms of Use, might be in place after the publication of this article).

More guidelines on Solution Diagrams & Icons can be found in this article by Bertram Ganz.

References

[1] Cowboy coding - Wikipedia

 

 

 

 

 

2 Comments
Eugevi01
Explorer

Hi. Excellent article!!!!!!! 

I usually giveworkshops on ACT100-200, as well as provide support as an Architect in projects, and what you mention that is confusing is "as is". Being Agile does not imply lack of control, but rather a way of "managing work" where, for example, you are really involved in the "business", and "do not wait to try at the end", but on the contrary, it is bring from Agile the concept of "design in sections, show and detect early if we are on the path that allows the user, at the end, to have a functionality that they understand, give value to and will really use"

Another tool that I usually recommend is to use the concept of MVP (skeleton or the minimum necessary so that the minimum functionality that is initially required, to satisfy that critical and core operation that the client requires, taking into account that this criterion must always be integrated within each process (that is, not losing the integrated or entire vision of the solution). And that this must be worked on from the “Discover” (the ideal would be to be able to work with the Client on this change of vision beforehand).

The “Working before” thing is because, in my opinion, something is still missing at a general level, which is that companies are really aligned with an Agile approach throughout their structure. (And this also goes for freelance consultants/partners and vendors).

They want to implement Agile as if it were just a “set” of steps or rules when it implies “changing the mentality of all its participants.”

For example, many times when one tells the “sales” area that the client must first sell an “assessment” to see “what would be the best approach, to achieve that flow of scaled growth, starting from an MVP to each time to use each function more (that is if I enable the app.

In some cases because they have not changed their mentality, and in others, many, because clients still want the “closed package, with scope x”, without having first given a space to really see what that scope implies, they only say, FTM followed by an AA-FI-AP AR but what processes are you talking about, what do you want to cover, etc.), even though the RFP says Agile.

Or those who, when you tell them, "the business, the key users" require greater dedication, are surprised, or you tell them that the backlog must be led by them, (perhaps they have learned about that concept in the preparation phase, therefore they are It gets into confusion with user stories, requirements, mappings, etc., not to mention the shock when you say "the backlog is a living object." (in some case the same for the consultants…)

Let's say that OCM is necessary, not only during a project, but before, to incorporate Agile as an internal practice, where less and less micromanagement is observed, but more conscious leadership.

And yes, it would be good if we had these work practices from the early training of professionals.

For this reason, what you mention in your article becomes even more relevant about knowing how to be “judicious” knowing that hybridity is there, and perhaps knowing where you can incorporate that best practice.

(Besides, if we are being strict, Activate is based on PMI, and to this, it incorporated what it considered the greatest value it could give from Agile).

Regards

MartinMysyk
Product and Topic Expert
Product and Topic Expert
0 Kudos

Thanks for the thoughtful comments on agile. You mentioned some ideas I had not thought through.