I am sharing a post from our LinkedIn group on how to commence your journey:
Original Question:
How to establish agile development in a very tight and constrained department
“I have been studying Agile development (Scrum in particular) and wish to implement it within my team. Team is around 20 over developers, QA engineers and several key role personal (DBA, S.A,B.A and such). Problem being the team turnover rate is high. To add more complexity to the situation, lots of delivered products require CRs and bug handling while new assignments keep piling up, and the team keeps answering customer care 30%~40% of their time.
Is agile good for this situation? Is working in “small” amount of work units the answer to better productivity? I have my management full support to move the team forward into agile development yet I find it hard to drive it given the conditions described above. Any advice from the masters?”
@****, I am starting from the last part of your statement: You have full management support, which is wonderful. It means they trust you to make changes that are good for the organization. You will need to find out whether this includes also management commitment, that it, are they willing to change to accommodate your changes. If they don’t you will need to adapt in order to become agile while still answering their needs.
As for becoming agile:
The complexity you describe exists in many places, in many different manifestations. You will need to find a way that is suitable for your context. In order to do so, you will need to experiment, and find if what you do works well for you. If it doesn’t, you will need to design another experiment. If it does you will design experiments to make it even better, and to adapt to the changing reality.
The big question you must be facing now is HOW? How do I even begin to design the first experiment?
In order to design good experiments, you will need to acquire knowledge – both practical and theoretical. What makes an organization become agile, and what diverts it away from agility?
This can be done through experiences – courses and workshops. Practical Agile (my organization) runs such courses. Find out more about it here. Of course, there are others to choose from.
You can also read books. Shirly just posted in this group Agile Bench’s list of books by category.
I have recently posted Jurgen Appelo’s 100 most popular books on agile
What’s your idea of becoming agile?
If you’ve got your own ideas of effectively becoming agile, please share them! You can either share them as responses here, or, even better, respond directly on the post in LinkedIn, to help the guy by sharing your way. If you think I am wrong, or maybe not good enough in my response, heck, you will also help me grow better Agile Practitioners
I have heard more than a few times that games and simulations in training courses are irrelevant – specifically in Scrum and other agile courses. That doing Scrum using Lego bricks is too simplistic and does not represent real life in any way.
Similarly I have heard, and keep hearing, that the agile management tool should be selected early, even before the implementation starts. The rationale is that individuals need to learn the tool and become familiarized with it before they learn the rules; also that the tool will imply limitations that must be integrated into the process.
Empirical research suggests that this is not quite the case. Actually quite the opposite may be true.
I am starting my argument with a reference to series of experiments on rats, researched and partly conducted by Edward Tolman. In Cognitive Maps In Rats And Men, Tolman describes how rats learn a map in their mind. It is an interesting read, written in an easy to understand language, even if you are not in the habit of conducting research on social science.
Tolman describes, in one set of experiments, how rats that learn a maze without being stimulated (“incentivized”) to reach a food-box, improve their performance once food is presented – at least as much as rats that were stimulated for food from the first attempt. Moreover, some rats have learned the approximate location of the food-box and jumped out of the maze, running in a straight line to their goal. That is, rather than learning only the correct maze route, they also concluded the spatial location of the food-box.
This last spatial map has also been researched and is described in the same article. Even when the maze was subsequently blocked, and the orientation of the experiment setting turned 180 degrees, most rats figured out the location of the food-box relative to the room. That is, the rats understood where they want to get to, rather than how to get there.
The term Latent Learning describes this ability of learning without having to express it immediately.
Additional research proves that squirrels remember the location of their caches, not merely using smelling as a guide. See Jacobs and Liman research as one example for this. Moreover, squirrels returned to their own caches, not to nearby caches of other squirrels.
Initially these experiments tried to refute the ‘hard core’ behaviorists that suggested that learning can only exist when sensual stimuli is present. But they brought, as Tolman’s title suggests, a deeper understanding of learning and remembering.
How is this related to the title? And why do people think that learning by simulation or that changing agile implementation tools is not productive?
I believe that this is related to a common human dysfunction, a cognitive bias, called Functional Fixedness a term coined by Karl Duncker. This is the opposite of out of the box thinking: Say you are on a phone call at the office on your Android device, and the other party asks for a phone number stored in your phone book. Some people will search for the number on their phone, having to stop the conversation momentarily. Where is the functional fixedness? Since you are at the office, you could login to your Google account on your computer and get access to the entire phone book from the Contacts application, since Google automatically synchronizes phone and Google account.
The funny thing is that we are convinced that others suffer from Functional Fixedness more than we do, and we attribute others with tendency of not being able to change from one tool to another. The fact of the matter is that we are all functionally fixated at times, just like any other person. At the same time, we all have capacity to learn cognitive maps, and are able to adapt, just like any other person (even like most rats, as it turns).
So if you are embarking on an agile journey, and considering a tool, start by using a physical board and sticky-notes. Experience shows that introducing a CR (Change Request) to the physical board has an incredibly better time-to-market response, at a fraction of the cost, compared to changing other software based tools. Yes, even if this means making configuration changes to a free tool (as someone will have to spend time making and testing these changes).
Even when distributed teams are involved, the cost of a HD camera and Skyping daily stand-ups will be much cheaper than any online collaboration tool.
Now, please don’t get me wrong – I think that tools are important; and the bigger the organization the more important they become for visibility, collaboration, continuous planning and more. But it is much easier to make mistakes on a physical board, and start afresh next iteration, than carrying the history of your mistakes for numerous iterations to come.
Similarly, the importance of simulations during training course and workshops is immense. There is huge value in practicing though games and simulations while you are in learning mode, in Beginner’s Mind or Flow. Running several Scrum sprints in a couple of hours will help you practice Scrum while you are focused on learning it. When you learn Scrum on the job, while you are busy with yesterday’s bugs, where to eat lunch and your upcoming appraisals is rarely as effective as learning during a training course.
We tend to believe that we are rationale beings, not affected by patterns; that once we tell ourselves to try out a new thing it will work right away. Evidence suggests that our minds are more complex this. Learning the principles of agile using simulations and then practicing through one tool later implementing another appears to work. Just as learning to ride on a training bicycle and gradually advancing to specialized models.
Everyone’s talking about agile. This is the hype in software development process – the fashion, the Mode. It is so much in the Mode that we sometimes forget that our purpose in life is to produce quality, endurable, appealing software. Scrum, or any other agile framework for this matter, is a means, not a goal in its own right.
A friend gave me permission to share this image with you: Can you spot the differences?
Let’s hypothesize what has happened here:
Two error messages were displayed in a very different fashion. Why?
Because they were introduced by two separate developers. Why?
Because one is technical and the other is more business oriented. Why does this matter?
Because there was no one shared mechanism for messages for the user. Why?
Because it had to be finished within the same iteration. Why does this matter?
Because in agile there is no time to build such infrastructures.
Is that really so?
Scrum is no excuse for technical mediocrity. On the contrary – it is an opportunity to improve, based on two major features of agile:
Scrum does not introduce problems. It exposed them. In this example, this is an opportunity to deal with such a scenario now rather than later. In a traditional project, such a failure can also occur. An iterative-incremental process helps here on two ends:
– The feedback loop is much shorter
– A sustainable solution, such as a framework to display messages, can be introduced in the next sprint, rather than the too-well-known “We will deal with it in the next version” (also known as “It will never happen”)
When the team encounters similar tasks, they should identify that they fall into the DRY – Don’t Repeat Yourself, category. When you find you are doing something repetitively, such as forming a message box time and again, this is a good time to make it happen in one place. It may cost an extra hour in the current iteration, but it will save dozens of them in maintaining those messages, should you make general changes to them.
If you are one of the agile-skeptics, I strongly recommend you take a course to learn what it really is about. Especially if you are working in an organization that practices agile – you might be doing damage not only to the organization, but also to yourself. So next time you encounter such an agile-makes-things-worse moment, think maybe it is not agile who is not up to scratch, but your knowledge of it
There are many reasons to go SCRUM in particular or agile in general. Each organization will have their own reasons and motivations. According to the 2011 State of Agile survey, top three reasons are to increase time to market, to cope with changing priorities and to increase productivity.
The question is, how do you know that you are getting there?
The default answer for most is KPIs. Measure it, and you will know that you are there. The problem with measurements is that they are very elusive. You want to measure one thing, and ending up affecting another. Regardless of the measurement, you may impact something that you didn’t intend to.
Why is that so? This is because when you measure things, you leave a trail, and this trail is not merely the guide to go back, it is also the guide to go forward, a kind of a forecast to the next target.
In fact, a trail is more useful to going back in order to fix things, rather than to predict where to go next. Take breadcrumbs navigation: It helps you go back in the application to re-navigate; it also helps you navigate faster on successive uses of the application. But it doesn’t help you predict what you are going to do. It can help you measure what users are doing most, in order to improve the navigation. Like in Hansel and Gretel, the kids wanted a trail back home, not a guide to go forward.
Take an example. Many teams use velocity as their planning tool. They use the amount of done stuff, in relative size, in order to plan how much they can sensibly fit into the next iteration. It is a planning tool, not a measurement.
Yet, organizations try to use this velocity to do more than planning. After all, velocity can be a good measure for productivity or even predictability, can it not?
Yes, if your organization’s main business is velocity. When were you last asked by your customers: “For the next release we would like to order 54 points and 21 epics, please”? Is this the kind of predictability you require?
Check out Smith and Jones Predictable Lighthouse sketch – are you convinced that predictability is something you welcome that much anyway?!
What kind of trail can you use that will record something deliverable, and not an artificial, game-able, number that can have collateral impact that is potentially undesirable?
Let’s examine few of the options:
Velocity: Dear team, please provide more story points.
No problem, dear manager. We’ll just skip all those tests, and the number is set to increase. Given that we do not provide the support, escaping defects will be anyway handled elsewhere.
Predictability: Dear team, please provide a consistent number of story points.
No problem, dear manager. We’ll just provide the same number of points. When something big comes in, we’ll just bloat the estimate, so we don’t have to deal with breaking to smaller stories.
Cycle time: Dear team, please provide a standard ratio between points size to the time to develop it.
Now here’s a good one. Cycle time can actually be a rather useful trail. But only if you consider it from a systemic point of view – which makes it much harder to measure. Otherwise, it may become similar to velocity
The problem with all the above is that it mixes several concepts into one number. The trail and the measurement are not one and the same. This is why using points or velocity as a measurement is risky. It becomes goal in itself, rather than means to a goal.
In such a trail, for every story you specify, in business context, WHAT is the system expected to do. This specification is turned later to an executable sequence that will verify that the developed code does WHAT it is expected to do. Note, that specification by example is not about HOW, it is about WHAT.
This makes a trail of business rules that have been proven, and are now part of our regression suite, and upcoming trail that is what business rules are to be proven in the coming iteration. In an analogy to the breadcrumbs navigation, where have we navigated so far, and where are we navigating to now. Note that over specifying (forecasting several iterations ahead) is likely to become waste.
Recall from the top of the post, the trail helps you go back and make corrections. In this executable specification trail, it enables you to either fix business rules that got broken due to changes, or to remove redundant rules – and code, in order to navigate better in the future.
Coming back to measurements – this trail is not a measurement. It is a trail.
If you must measure, try to check, for example, how many routes you are navigating on concurrently. WIP can be a good measurement for that. Yuval Yeret has a good explanation of WIP and using CFD to measure it. Once in place, you can start measuring also cycle times, but as a supporting tool for your WIP, not as a guide to limit story duration.
Alternatively, try to use Agile Earned Value Management (EVM). You may read about it in Tamara Sulaiman’s article here. While Agile EVM is useful for planning against budget, it has some hidden assumptions, such as scoping for the entire release.
The merits of one measurement or the other is the subject for a separate post. I will just comment that I like these measurements more than others because a) they are good tools for decision making, and not merely measuring; and b) indeed they are based on the trail but not measuring it.
As long as you remember that the objective of the trail is to correct yourself – to make the right decisions, you will be ok. Don’t force measurements if you cannot effectively use them for decision making.
Otherwise, you may find that you were hoping for breadcrumbs and instead of SCRUM you we left with, well, just the crumbs and no trail.
The 8th Agile Practitioners IL meeting took place on May 30th 2012, at SAP offices in Raanana.
Loyal to the title of the meeting, Agile Playground, we played two games highlighting agile values.
The first game was based on Alistair Cockburn’s version of James Shore’s Offing the Offsite Customer game. It is a fantastic game to experience many aspects of agility: iterative and incremental process, inspect and adapt, short feedback loops, and many more. To me, when introduced by Alistair Cockburn in the 2009 Scrum User Group, I have learned on agile requirements in less than an hour more profoundly than many other learning opportunities I have had before and after.
Judging by the discussion that followed, participants devoted themselves to the session, and I hope we succeeded to have similar influence.
In the second part, Lior Friedman facilitated several estimation techniques, including planning poker, silent sorting, and relative sorting. Not surprisingly, this exercise proved once again that absolute estimations yield vast variance between individuals and teams – up to 10 fold, compared to relative estimations that yield in majority of cases not more than one notch difference between teams.
In the video below you may see a very uncommon sight in a group of Israeli software experts: a large group of more than 30 people exercising silent sorting
We would like to thank our hosts at SAP Israel for their warm hospitality, and, of course, all participants, loyal patrons as well as newcomers for coming to the group meeting
See you in AP_IL #9
P.S
AP_IL #9 and AP_IL #10 are already planned with contributors from the community. Follow our linked in group Agile Practitioners IL to find out who is going to be there.
If you would like to share, or you would like one of our sessions to focus on a specific issue – please let us know – These meetings are all about sharing the agile culture with all of us!
Hindsight is a strange thing. In hindsight it is easy to criticize. It’s unimaginable to find someone still convinced that the world is flat. It’s easy for us to say ‘how didn’t the US see Pearl Harbor coming?’
Of course, we have something that those that didn’t see all this didn’t have: hindsight.
Quite naturally, there are things for which we do not have hindsight: will this release be successful in marketing terms? Will this new product live to its promise?
Within a given time period, we will be able to say whether the release was successful, or whether this new product made the impact we anticipated for it. But then it will be easy – it will have become a past event, and we will be able to do nothing about what happened prior to the event.
This is a problem that can never be solved. No one will be able to tell you with certainty what will happen in the future. On the other hand, you could get a good estimation of it.
Say that the release is scheduled for one week from now, and we have not even gone through 50% of the progress, and we have been working on it for 8 weeks already, and nothing is working. One can say, with a fair degree of certainty, that marketing success is somewhat not plausible.
If, however, we would have checked after two weeks whether the work we have done so far is working. And we will have continued every two weeks to make similar checks, we could, quite reasonably have reached 80% progress after 8 weeks. Knowing that these 80% worth of software is working according to the customer needs, we would be more comfortable to say that we might be successful in marketing terms. Right? Well we cannot be certain, but we will have a better chance.
The same with the new product; if we have a group of business users having a look at the product every two weeks, we will be better positioned to estimate whether it will live to its promise. Right?
This is not hindsight. Not even close. But it provides a better starting point at the time we need to provide such estimates.
This is what agile is about. Getting shorter feedback loops, so we can make decisions earlier, so we can prepare ourselves and gear ourselves with relevant empirical data.
Meticulously planning ahead of time provides nothing except having theoretical plans. Redefining the plans according to the future, as it changes it shape due to current event, will help us face this future more prepared.
Therefore planning is good, as long as you don’t overdo it. In contrast, Reacting to events will prepare you better for the future. This is counter intuitive for many of us. But think of butterflies – if they plan their day, it will be a disaster for them. They only need the grand plan; No details. Then observe the environment and react.
In the language of the Agile Manifesto: Responding to Change over Following a Plan
So what does a butterfly say at the end of the day?
Our intuition tells us that if we tell others to do something, they will do it. However, we rarely apply the same intuition on ourselves. Say someone else put the suggestion box – how inclined would we be to participate and contribute new suggestions?
A learning team needs to nurture a learning culture. Think of those two words: nurture, culture. This implies that we need to cultivate it, and provide the fertile grounds for it to sustain.
Recently Mark Levison provided us one example of how to overcome technical debt and to increase the team’s evolvement and evolution into a team that learns how to learn.
He has used Michael Feathers’ brillirant book, Working Effectively With Legacy Code, to try out techniques of carving out problematic areas of our code, and refactoring them into code that is more maintainable and sustainable.
The point is one of courage. Will you be the first to lead this change? If someone is already leading such a transition, or attempting to, will you be courageous enough to join the ride? Take Derek Sivers‘ short clip about the underestimated kind of leadership – being the first follower.
Courage, as I have found out, is something you realize in the aftermath. Looking back in retrospect you say to yourself – “Where did I find the courage to do this?”
The order “Be courageous” in that sense is about the same as saying – put your suggestions in the box. If you are looking for courageous people, think whether you, as a team, are cultivating the atmosphere for such behaviors to emerge.
Not sure how to start? Make the first courageous decision, and get educated on the values, principles, and practices that will get you there.
Taking a good SCRUM course may be a good starting point. My colleague Elad Sofer is running a SCRUM course at the end of April (as do several others in Israel, and many around the world).
It is one thing testing a standalone application, or a monolithic website. It’s quite another testing a platform capable handling millions and trillions of events per day. In the same token, it is one thing verifying the user and install guides of a mobile app. It is quite another verifying a mammoth document of a system consisting of thousands of complex operations and endless configuration options.
Indeed, with an agile mindset much of the overheads can be dramatically reduced. In similar concepts of identifying the impact of a single class on the entire build, it is possible to analyze the impact of altering one operation on the entire document repository. But such large systems rarely have anything near good coverage of the documentation to carry out such an analysis.
Welcome to the world of non-functional testing. What comes naturally to small organizations becomes a problem in its own right in larger ones. The examples above are just two of a much wider scope: Platform combinations, multiple UI channels, operational aspects (such as EOD or backup and recovery) – all become big issues in large systems.
A few compelling ideas to handle such challenges will be presented in the upcoming 7th Agile Practitioners IL meeting on April 17th at WebCollage offices in Tel Aviv.
During this meeting Karen Schlaien will share her experience as a testing director at Amdocs.
The presentation will be followed by a cool game of testing. As always, refreshments and mingling are an integrative part of the event.
Software engineering is defined in Wikipedia as follows: “…is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches;” and so on. Intrigued by ‘disciplined’ in the definition and lack of it as seen in some organizations, I wondered how is this seen in other professions. Say, an airplane pilot, for example. What are the differences between learning to ride a bicycle, for instance, and learning to fly an airplane?
Therefore, I was reading through the Airplane Flying Handbook to figure out what makes a good pilot?
Not surprisingly, the following text, extracted from the handbook, it found at introduction chapter: Read more…
All things, great and small, come to an end, eventually.
So are new posts to this blog.
I am currently writing mainly to our blog at Practical Agile. You are most welcome to visit our website and blog.
Becoming agile 