Becoming agile

Agile, through the storms

Archive for the tag “agile manifesto”

14 May 2014

Ten Tips for the New Scrummer

What makes a good Scrummer? Well, if I knew an exact formula, I would be too busy selling it to Scrum-wannabees than writing tips about Scrum 😉

On a more serious note, the differences between organizations is so great, that any ten tips will never be good enough for all.

Nonetheless, I’ve gathered some of the things I found helpful in early stages of Scrum adaptations.

I hope that many will find this useful, since ‘Early’ is also organization specific – some teams I’ve encountered have become self-managed in less than 10 weeks, whereas other teams still struggled with the basic concepts after six months (and more) of doing Scrum.

So here it is – my Ten Tips for the New Scrummer:

  1. Start with a project small enough to become a success, yet important enough to attract decision makers.
    It is not uncommon to see organizations start with multiple concurrent teams going Scrum, which makes the transition effort much greater than required. Instead, generate success by building a Scrum team that will give management the ‘appetite’ for more.
  2. Celebrate small successes.
    Focus on what’s working well. Peel-off all the cynicism that we so frequently meet in IT organizations, and find that people still love when told that they are doing good.
  3. Appreciate that Scrum is a very different than traditional software development projects.
    It is unrealistic to expect people who didn’t do Scrum before, or are fairly new to Scrum, to adapt to concepts that may seem counterintuitive at first.
  4. Read the Scrum Guide. If you’ve already read it, read it again after a while.
    This is a great concise description of Scrum, and you’ll learn something new with each time you re-read it.
  5. Speak of forecast, and refrain from talking about commitments.
    There are good reasons why the authors of Scrum chose ‘forecast’ as the team’s indication of what they will achieve in an iteration.
  6. Start-off with sticky notes on a wall or whiteboard, and postpone choosing an electronic Scrum tool for as long as you can.
    Deploying a change-request on a physical Scrum board costs almost nothing. Asking for a change request on a commercial tool might block you for a long time. Making your own tool – unless you plan to sell it for big bucks – don’t do there!
  7. Learn. A lot.
    The team you are a member of should expect itself to inspect-and-adapt indefinitely. What better way do you have than increasing your knowledge to have great ideas for your retrospectives? Read books, attend courses and workshops, read blogposts. The return on this investment is priceless.
  8. Learn to trust relative estimations.
    Learning to estimate and to continuously plan in a way that reduces overloading teams is critical, and one of the hardest transitions from traditional software projects. Relative estimations are key to letting go of unrealistic plans.
  9. Excel in your engineering practices. No matter how well you do Scrum, if your testing cycle is too time consuming, if  the feedback-loop on writing new code takes too long, or if your coding standards are inadequate for short iterations – you will hit a brick wall without paying your technical debt.
  10. What are your 10 tips?
    Really, what ten tips would you give someone who is thinking about doing Scrum?
    If you can’t come up with ten good tips, either you’ve got more learning to do, or you are going through a stressed phase and need to let go, or maybe Scrum is not right for you. Whatever the reasons, if you want to succeed in Scrum (and agile SW development in general), find ways to become passionate about it.

Of course I could be writing fifty or a hundred tips or more: invest in agile requirements, sharpen your Definition of Done, how to decide on the Iteration length, Always have a well-groomed backlog for Iteration start, … I arbitrarily chose a good selection of important ten tips.

Wanna give Scrum a go and not sure how? Start with a course. It will take you through the paradigm shift that comes with agile, you’ll get to try it out in a workshop setting, and it’s fun. You’ll be far more equipped for your first Sprint than any blogpost you’ll read. Drop me a line if you’re not sure.

Posted in Agile and tagged , , , , , , | Leave a comment
08 Oct 2013
6 Comments

Gantt Fetish

“A fetish (derived from the French fétiche; which comes from the Portuguese feitiço; and this in turn from Latin facticius, “artificial” and facere, “to make”) is an object believed to have supernatural powers, or in particular, a man-made object that has power over others. Essentially, fetishism is the emic attribution of inherent value or powers to an object.”
Source: Wikipedia, http://en.wikipedia.org/wiki/Fetishism

Engineering projects, and software projects are no exception, tend to become complex and challenging. Naturally, the bigger and the more individuals are involved in making it, the projects becomes more complex.

Also naturally, when organizations make projects, they wish to simplify them. To make them more visible and understood, so that they are more controllable and manageable. One aspect of this complexity is to understand the dependencies between steps towards completing the project.

Luckily there is a widespread tool to achieve visibility of such dependencies within the project: The Gantt Chart.

“A Gantt chart is a type of bar chart, developed by Henry Gantt in the 1910s, that illustrates a project schedule. Gantt charts illustrate the start and finish dates

of the terminal elements and summary elements of a project. Terminal elements and summary elements comprise the work breakdown structure of the project. Some Gantt charts also show the dependency (i.e. precedence network) relationships between activities. Gantt charts can be used to show current schedule status using percent-complete shadings and a vertical “TODAY” line...”
Source: Wikipedia, http://en.wikipedia.org/wiki/Gantt_chart Emphasis added.

A typical Gantt chart might look like this:

A Gantt Chart

Source: de.wikipedia.org, http://commons.wikimedia.org/wiki/File:OpenProj-screenshot.jpg1

The advantages of such a chart include that it can quite clearly show the project’s critical path, its progress (how much was done, and how much is left to do), when to expect its completion, and more.

How does this relate to fetishism?

Let’s describe a plausible scenario of creating a Gannt chart with dependencies in a project. Our project consists of changes in three integrative products and ten teams of engineers across these products. In the beginning, product managers in each of the products create a list of requirements, and lay them
down on a Gantt chart, and then they work together to combine a composite Gannt chart to visualize the expected work on the entire project, including all three products.

So far there is some waste in this approach, yet it could be attributed to a necessary waste2.

At this point I wish to draw your attention to a feature of Gannt charts: the milestones, typically denoted as a diamond symbol (‘♦‘), as in the chart above.

In order to meet a milestone we need to know whether there are dependencies between tasks, and in our plausible story, the VP development has asked all teams to provide all dependencies in the project: which team/person you depend upon, and which team/person depends on you. “Please provide this
information by end of the week”, said the manager.

Of course, none of this can occur in your organization. This is only hypothetical. A hypothetical plausible scenario.

The result is that all teams and all their managers are now engaged in reviewing all the activities to be completed by the end of the project, attempting to provide dependencies.

This is likely the complete opposite of principle #7 of the agile manifesto: “Working software is the primary measure of progress”.

And yet, all these people are now working towards a common goal: provide all dependencies by EOW.

Recall that fetish “is an object believed to have supernatural powers, or in particular, a man-made object that has power over others”.

Seemingly this is good: Everyone, or at least many, are now working together towards a common goal. However, the object of this goal is not the real thing (making working software). Rather, all are working towards an object that is believed to provide powers that will enable managers to better monitor and
control the execution of the project. Nothing to do with working software. Nothing a sensible customer will be willing to pay for.

Moreover, among the top reasons for project failures are changing requirements (11.8%), unrealistic expectations (5.9%) and unrealistic timeframes (4.3%), according to the 2011 Standish Group Chaos Report. According to State of Agile 2012 report, the second most important reason for going Agile is changing requirements, by 29% of respondents.

It goes without saying that investing days of work in getting all known dependencies in a Gantt chart (or any other media, for the sake of the argument) is a largely futile exercise.

In his 1988 book, The Workplace Within, Larry Hirschhorn refers (to management training techniques) as follows: “[These]… will fail, of course, if the technique functions as a fetish. Fetishes are not transitional objects. Like sexual fetishes, they block relationships between people and are used inflexibly. Social-scientific methodologies that are used indiscriminately function as fetishes.”

I do truly that Gantt charts are a good thing – as long as they are not being used indiscriminately. I have worked with a Scrum team that produced a Gantt chart during every Sprint Planning ceremony. At first I felt opposed to the idea. I talked to the Scrum Master about it, and he said it’s working for them, and I said nothing more. The truth was that it was working for them – it helped the team deliver more responsibly and predictably.
A few months later, they stopped using it – the tool was not required anymore. They were not using it indiscriminately.

At the end of the day, the object of our work is working software. Visualizing dependencies or milestones or critical paths is important if, and only if, it effectively contributes to the working software of the project it relates to.

Update – 2013.10.15:
In response to referring to his book, Larry Hirschhorn points out Eli Goldratt’s Theory of Constraints as an alternative to mapping dependencies (Thank You!).
My interpretation is – rather than spending time on identifying dependencies, look for bottlenecks (“Buffers”, in Eli Goldratt’s terms) and attend to them, until new bottlenecks are found, and repeat forever. Set the pace of the process according to the observed pace of the slowest bottleneck (“Drum”), and let all other elements in the process observe this pace (“Rope”).

1Gantt chart image by Projity Incorporated (http://www.openproj.org/product-overview) [GPL (http://www.gnu.org/licenses/gpl.html), GFDL (http://www.gnu.org/copyleft/fdl.html) or CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0/)%5D, via Wikimedia Commons

2of course one could argue that this whole concept is a waste: that creating a single backlog and not attempting to draw the anticipated progress is more sensible. This may be the topic of a separate blog post.

Posted in Agile, Human Relations and tagged , , , , , , , , , , , , , ,
18 Dec 2012
5 Comments

The Agile Man-ifesto

I have observed recently that of the signatories of the Agile Manifesto, 17 are men, and the rest are women. This made me think about the relevance of the manifesto, in terms of the intellectual, emotional, and cultural diversity that led to its creation.

I searched if someone else has published articles or works on this interesting fact, that all the signatories are male, and did not find anything about it. I did find, however, and the article Empower Gender Diversity with Agile Software Development by Prof. Orit Hazzan The paper shows that teams with mixed genders present better communication skills and better relationships. Furthermore, gender diversity in teams and in pairs resulted in members significantly reporting on more collaborative work. Did anyone mention Individuals and Interactions?

The Agile Manifesto source: http://agilemanifesto.org

The paper refers to additional work, and lays ground for future empirical work on the contribution of gender diversity on trust within teams, enhancing cross-functional teamwork and other aspects. This all suggests that encouraging women leadership and involving women in development teams enhances organizations’ ability to produce more and better quality software for their customers.

This got me intrigued. I browsed renowned agile books written be women: Johanna Rothman, Esther Derby, Diana Larsen, Lyssa Adkins – all books I found were published during or after 2001! (Admittedly this was not an extensive research only browsing in online bookshops)

Even the references in Prof. Hazzan’s article above – all referenced papers by herself were published after 2001.

I then contacted Prof. Hazzan and asked her if she has noticed this, and whether she knows of work done in this respect.

The answer came quickly: Read more…

Posted in Agile, Human Relations and tagged , , , , , , , , , ,
28 Nov 2011

What has NATO got to do with agile practices?

In one of the most influential articles I have read on the values behind agile, Alistair Cockburn refers to the 1968 NATO conference.

The Science Committee that brought forward the task of assessing the field of computer science, and its recommendation in 1967 to hold a working conference on Software Engineering. The term Software Engineering did not publicly exist until then. It was chosen as being provocative deliberately, checking the boundaries between practicing computer programming and other established branches of engineering.

I have read this article several times, and keep coming back to it. To me, it explains quite a lot of what has happened in the 40 odd years following the conference.

Interestingly, in 1970 Dr. Winston Royce introduced the paper
“Managing the Development of Large Software Systems”, commonly known as the Waterfall process. This pseudo engineering form was described by Dr Royce himself as being flawed. Yet, it was, and largely still is, the most practiced methodology for software development for decades.

If you, like me, want to learn a little more on the history that led us to where we are today, you are more than welcome to the 5th meeting of Agile Practitioners IL.

Meet Gil Zilberfeld, and hear on the fascinating ten year history since the Agile Manifesto:

The Agile tribe war – A 10-year history lesson

In the beginning there was the Agile Manifesto, and everything looked peachy. And then the universe exploded.

10 years later, we’re in the (post?) agile era, where different tribes are off to win the “we were right” cup. There are the craftsmen, scrum people, lean people, the post-agilists, and everyone else in the middle trying to make sense of this thing called Agile, what really works and how much it really costs.

How come the agile principles that were supposed to be the Great Unifying Theory of software, opened a tribal war we’ve been seeing the last few years? Is agile the real answer, or simply a filler between the waterfall and the next hotness? 

Join me in a travel through time, to piece together a puzzle of politics, money, intrigue, and yes, even software, and come up with a better understanding of what the hell really happened here and where we’re going from here..

The meeting will take place at Amdocs offices in Raanana, Israel, on Sunday December 4th. Gathering and mingling starts at 17:30, and the talk starts at 18:00.

Hope to see you there!

And a quick reminder:

Agile Practitioners 2012 conference is offered at special Early Bird prices.

To view the program and to register, visit our website at http://www.agilepractitioners2012.com/conference-program

Posted in Agile and tagged , , , , , | Leave a comment

Post Navigation