Some thoughts on Agile

Tags

agile, development process, product owner, requirements, specifications

I work (or so I think or imagine) with Agile principles for some time, but in all honesty not long enough to call myself specialist in that area. I do though have some thoughts I wanted to share with you, especially with regards to requirements and time it takes to deliver product to market.

Namely, I think that it is easier for agile principles in software development to show themselves when requirements are hard in nature, by which I mean if those are closely related to mathematical or other scientific formulas, where there is not much room for human involvement. There is set collection of rules product needs to follow and those are not disputable. Here I think products such systems for stock management, cashiers, nuclear plant security and similar ones are good example. Human wishes in such projects are limited mostly to GUI, sound of an alarm and shape and form of a report, not much else. And that makes things easier.

Things are different when human wishes are major part of the requirements or specifications of the product. Humans react to conditions, are susceptible to moods and are forgetful or simply change their minds often. If you don’t deliver in short enough time to satisfy latest wish list, you run a risk of having to endlessly introduce changes or start all over (third option is that product owner stops this requirement craze and decides himself on Minimum Viable Product – making it his product and most of the others unhappy). Agile is supposed to be good at it, but reality is such that some of those wishes will go unanswered if you want to deliver a product at all. People will be unhappy because of that and this is possibly what gives the method bad reputation.

Last thing is a role of product owner, having all-encompassing responsibility over product, from conception, vision, creation to marketing and sales. This obviously requires others to stand back and cede at least part of their responsibilities to one person who is supposed to know it all. Alone this causes resistance – how can it be that one person knows all of those areas to be able to create a good product? It takes organizational courage and discipline to at least try without micromanagement or meddling. Not mentioning the fact that good product owners are not found easily, again adding to bad reputation.

Agile is though not any different from many other ways of doing things, at least in principle. The fact is that if you do anything halfheartedly, it is bound to fail or bring poor results at best. If you are disciplined and give it all needed support, it will have a chance of success. Especially when you will also accept the fact that a product’s failure on market is not necessarily related to the way such product was brought to life.

What I Read – HBR May 2016

Tags

agile, Darrell Rigby, definitions, Harvard Business Review, HBR, Hirotaka Takeuchi, innovation, Jeff Sutherland, understanding agile

Recently I read somewhere, that I should make notes of what I read and review them from time to time. I decided to give it a try, since I read a lot and I think making such notes will be for me a way of remembering best ideas, quotes, or whatever from my books and magazines. I also decided to share those notes with you, in edited form as some have gotten pretty long. Just as a note – in many cases I copied whole passages without noting the page numbers, which is against good reference practices, but of course I will list title and author of a book (or article) where I got the notes from.

I do that with hope that at least some of you will reach for mentioned magazine or book when you will find my notes interesting. Ach, one more thing: small number of notes do not mean that the book or magazine was not good…

This is what I found interesting in Harvard Business Review, May 2016 issue:

Article “Embracing Agile” by Darrell K. Rigby, Jeff Sutherland, and Hirotaka Takeuchi.

[…] By taking people out of their functional silos and putting them in self-managed and customer-focused multidisciplinary teams, the agile approach is not only accelerating profitable growth but also helping to create a new generation of skilled managers.

[…] When we ask executives what they know about agile, the response is usually an uneasy smile […] But because they haven’t gone through training, they don’t really understand the approach. Consequently, they unwittingly continue to manage in ways that run counter to agile principles and practices, undermining the effectiveness of agile teams in units that report to them. These executives launch countless initiatives with urgent deadlines rather than assign the highest priority to two or three. They spread themselves and their best people across too many projects.

[…] Innovation is what agile is all about. Although the method is less useful in routine operations and processes, these days most companies operate in highly dynamic environments.

[…] we have discerned six crucial practices that leaders should adopt if they want to capitalize on agile’s potential.

1. Learn How Agile Really Works

[…] It comes in several varieties, which have much in common but emphasize slightly different things. They include scrum, which emphasizes creative and adaptive teamwork in solving complex problems; lean development, which focuses on the continual elimination of waste; and Kanban, which concentrates on reducing lead times and amount of work in process.

Rest of this point provides a short description of what scrum is… very useful to read it in whole.

2. Understanding Where Agile Does or Does Not Work

Agile is not a panacea. It is most effective and easiest to implement under conditions commonly found in software innovation: The problem to be solved is complex; solutions are initially unknown, and product requirements will most likely change; the work can be modularized; close collaboration with end users (and rapid feedback from them) is feasible; and creative teams will typically outperform command-and-control groups.

3. Start Small and Let the Word Spread
4. Allow “Master” Teams to Customize Their Practices

[…] If a team wants to modify particular practices, it should experiment and track the results to make sure that the changes are improving rather than reducing customer satisfaction, work velocity, and team morale.

5. Practice Agile at the Top

Some C-Suite activities are not suited to agile methodologies. (Routine and predictable tasks – such as performance assessments, press interviews, and visits to plants, customers, and suppliers – fall into this category.) But many, and arguably the most important, are. They include strategy development and resource allocation, cultivating breakthrough innovations, and improving organizational collaboration […]

6. Destroy the Barriers to Agile Behaviors

Research by Scrum Alliance, an independent non-profit with 400,00-plus members, has found that more than 70% of agile practitioners report tension between their teams and the rest of the organization. Little wonder: They are following different road maps and moving at different speeds […] Here are some techniques for destroying such barriers to agile:

• Get everyone on the same page (also those teams which are not working using agile methodologies – RC).
• Don’t change structures right away; change roles instead.
• Name only one boss for each decision. People can have multiple bosses, but decisions cannot […] Other senior leaders must avoid second-guessing or overturning the owner’s decisions. It’s fine to provide guidance and assistance, but if you don’t like the results, change the initiative owner – don’t incapacitate him or her.
• Focus on teams, not individuals.
• Lead with questions, not orders.

Excellent article summarizing what agile actually is and giving good examples of its application not only for software related projects, but also across all organizational levels. Well worth reading in whole – if I could, I would copy it whole here 🙂 The main take away, next to some handy definitions and explanations, is the fact that agile is proven to work in software industry or IT, and now is on the way to transform other industries or functions. As article states in last sentence: Those who learn to lead agile’s extension into broader range of business activities will accelerate profitable growth.

I Think R&D Does It Wrong (Sometimes)

Tags

agile, idea, process, R&D, scrum

Current R&D practice based on agile way of doing things is that R&D accepts the project and passes it through various departments, such as Systems Analysis, Test, Release Management, Licensing, etc. At the end of that process there is a hand out of a seemingly ready project, which should involve a license (where and if needed), set of documents (such as manuals) and a training session for requester. During that process though, since obviously it takes time, the requester is not really involved, or at least her involvement is limited to planned reviews of various milestone related meetings. The more the project is complicated, the longer it takes to complete it and the wider spaced are the milestone meetings. If R&D is quick with delivery, then the requester is busy checking (working with) new releases and is kept happy with some tangible progress. But if not, or if the project is truly complicated, requester (or customer) is forced to make adjustments in the original request, in order to adapt it to needs evolving from passing time. This is a fact of life: things change when time passes and original ideas seldom fit new reality. It needs to be continuously adapted, leading sometimes to great changes which often make idea from the start of work completely irrelevant and different to what comes out at the end.

This leads to following issues, just to name the few:

• Projects are never finished. If they take long, they always are being adapted or adjusted. This adaptation and adjustment takes life on its own.
• Projects are abandoned after a lot of work was put into them. This because passing time made them obsolete. Here some organisations pursue those dead horses anyway, just because.
• Projects are way out of the budget. Time is money.
• Ready projects are never truly being handed over. Because of the time spent on the project the only people who really have an idea about the product are the ones who developed it, meaning the same people are the best suited to support it. Proper training session would have to be very long to make any sense, practically for a long time product is in fact supported by R&D, draining resources needed for other projects.

So what can be done? I think that R&D does it wrong and the whole project management needs to be rethought. I am sure that involvement of requester needs to be much greater than it is now. I would envision a project team where a representative(s) of technical support and/or sales are involved as of certain development stages in order to:

• Ensure a smooth hand out. Since technical support is involved in development, they are already trained and know the product.
• Ensure ease of licensing. Sales would know, that what they are getting is what they needed.
• Usability would be ensured. Sales would get not only what they want, but also how they want it. What developer considers to be good enough, market or users often find very difficult to use or at the extreme, completely useless.
• Involving requester in development work could also result in more understanding as per what development means and maybe result in less adaptations or better specifications in the future projects, saving time in the process.

I know that this is not yet mature. But it is a start and I am sure that the idea is worth pursuing further. If it hasn’t already been – I am not so sure that I am the first who thought of it… 🙂