issue 13

The Magazine for Agile Developers and Agile Testers 

Kanban 

www.agilerecord.com free digital version made in Germany ISSN 2191-1320 

February 2013 

issue 13

© Sergejy Galushko – Fotolia.com 

CAT is no ordinary certification, but a professional journey 

into the world of Agile. As with any voyage you have 

to take the first step. You may have some experience 

with Agile from your current or previous employment or 

you may be venturing out into the unknown. Either way 

CAT has been specifically designed to partner and guide 

you through all aspects of your tour. 

The focus of the course is to look at how you the tester 

can make a valuable contribution to these activities 

even if they are not currently your core abilities. This 

course assumes that you already know how to be a tester, 

understand the fundamental testing techniques and 

testing practices, leading you to transition into an Agile 

team. 

Pragmatic, Soft Skills Focused, Industry Supported 

Book your training with Díaz & Hilterscheid! 

22.04.13–26.04.13, Frankfurt/Karlsruhe, Germany 

13.05.13–17.05.13, München, Germany 

24.06.13–28.06.13, Köln/Düsseldorf, Germany 

(German tutor and German exam) 

Open seminars: 

Díaz & Hilterscheid GmbH / Kurfürstendamm 179 / 10707 Berlin / Germany 

Tel: +49 30 747628-0 / Fax: +49 30 747628-99 

www.diazhilterscheid.com training@diazhilterscheid.com 

Page 2 Agile Record – www.agilerecord.com 

The certification does not simply promote absorption 

of the theory through academic mediums but encourages 

you to experiment, in the safe environment of the 

classroom, through the extensive discussion forums 

and daily practicals. Over 50% of the initial course is 

based around practical application of the techniques 

and methods that you learn, focused on building the 

skills you already have as a tester. This then prepares 

you, on returning to your employer, to be Agile. 

The transition into a Professional Agile Tester team 

member culminates with on the job assessments, demonstrated 

abilities in Agile expertise through such forums 

as presentations at conferences or Special Interest 

groups and interviews. 

Did this CATch your eye? If so, please contact us for 

more details! 

08.04.13–12.04.13, Stockholm, Sweden 

15.04.13–19.04.13, Oslo, Norway 

03.06.13–07.06.13, Amsterdam, The Netherlands

Dear readers, 

The Christmas season seems to be well behind us, as well as the relaxed pace of winter. The tempo for 

2013 has been kicked into full gear, working hard to keep up with the many fixed deadlines. 

We are currently conducting the Agile Dev Practices. During the organization of this new conference 

for developers, we have noticed that we are not the only ones who are very busy this early in the year. 

You all are quite busy as well! If you missed the chance to attend the Agile Dev Practices 2013, we look 

forward to seeing you at our other conferences in the future; for example the Agile Testing Days 2013, 

for which we have received a new record amount of papers. Keep checking out our website for current 

updates in the program this spring: www.agiletestingdays.com 

For some time now, I have been carrying around a new and exciting training concept. At the last Agile 

Testing Days I took the opportunity to discuss this concept with some agile gurus. We quite quickly 

decided to conduct the first version of the Agile Team Academy this year in Amsterdam, starting on 

September 16. Matt Heusser, Janet Gregory and Markus Gärtner have developed this new concept of 

training further, and are going to play a very important role this fall. During this four-day immersion, 

you will have the opportunity to work together with these four leading agile gurus, participating in many 

interactive activities, on a learning-by-doing basis. Don’t miss out on this exciting opportunity. Check out 

www.agileteamacademy.com. 

In this issue you’ll enjoy an immersion in the concept of Kanban. I look forward to hearing your thoughts 

on this issue. 

Enjoy reading! 

Best regards, 

José Díaz 


Editorial

Book your training with Díaz & Hilterscheid! 

CAT – Certified Agile Tester 

CAT is no ordinary certifi cation, 

but a professional 

journey into the world of 

Agile. As with any voyage 

you have to take 

the fi rst step. 

HP Quality Center 

Incorporate the abundant tool knowledge 

of HP Quality Center in this workshop: 

From the module architecture to 

analyzing and customizing. You will be able 

to confi gure your test project, utilize requirement 

data, execute effi cient test cases, and 

apply effi cient solution to discovered issues. 

HP QuickTest Professional 

This workshop enables the quick and effi cient 

Use of QTP. Discover the individual functions: 

documentation, reproduction, object repository, 

application of Sync points and Verifys, 

utilization of Active Screens, Features Data 

Tables, and the linkage to QC for automatized 

testing, producing and applying results. 

Agile Essentials 

This two-day course is aimed at anyone involved 

in software engineering who wants 

to become familiar with working 

in an Agile environment, 

giving candidates a solid understanding 

of roles, processes 

and techniques used in Agile projects. It provides 

an overview of the activities building on 

a basic understanding, reinforced through a 

heavy emphasis on discussion and practical 

application. 

IREB® Certified Professional 

for Requirements Engineering – 

Foundation Level 

This training course introduces you to the 

correct and complete specifi cation, documentation, 

checking 

and management of 

requirements. You will 

learn techniques, procedures 

and tools, and you will be introduced to 

the fundamentals of communication theory. 

The training course is aligned to the syllabus of 

the independent International Requirements 

Engineering Board (IREB®). 

In-house Training: All of our training courses are available as private/in-house training. 

Please contact us for details. 

Díaz & Hilterscheid Unternehmensberatung GmbH 

Kurfürstendamm 179 

10707 Berlin 

Germany 

Phone: +49 (0)30 74 76 28-0 

Fax: +49 (0)30 74 76 28-99 

E-mail: training@diazhilterscheid.com 

Website: training.diazhilterscheid.com 

ISTQB® Certified Tester 


In this training course 

you will learn about the 

most important test techniques 

and procedures 

that you can use to prepare 

and execute software tests effi ciently 

and effectively, and which will help you 

to make a decisive contribution to your 

project’s success. 

Advanced Level – Test Manager 

Building on the fundamental knowledge of 

the Foundation Level, this course teaches 

you all of the theoretical planning, steering 

and control tasks in test management and 

discusses your possibilities for their practical 

implementation using examples. 

Advanced Level – Test Analyst 

Based on the basic knowledge taught in 

the Foundation Level course, this training 

will teach you in-depth knowledge about 

technical testing tasks and review techniques. 

In this connection, your possible 

course of action in every-day work situations 

will be discussed with the help of 

numerous examples. 

Advanced Level – 

Technical Test Analyst 

Based on the basic knowledge taught in 

the Foundation Level course, this training 

will teach you in-depth knowledge for 

structure-based testing tasks and test automation 

matters. In this connection, your 

possible course of action in practice will 

be discussed with the help of numerous 

examples. 

For more training courses and current training dates, please visit our website or contact us: 

Online Training 

−60 % 

Save up to 60 % with online training! 

Visit our online shop to see what courses 

are available: 

www.te-trainings-shop.com

Editorial 1 

Editorial Board 4 

The Agile Project Manager: WIPping Things Into Shape 6 

by Bob Galen 

COLUMN: By the way… 8 

by Tanja Schmitz-Remberg & Werner Lieblang 

Kanban – Quo vadis? 10 

by Maik Nogens 

How to create the agile enterprise 12 

by Michael Azoff 

COLUMN: Creating my own flow with personal kanban 15 

by Huib Schoots 

The Day Dan Realized the Power of Kanban! 17 

by Raja Bavani 

The Kanbanist’s Guide to the Galaxy 20 

by Radoslaw Orszewski 

Cumulative Flow Diagram – Kanban Predictive Modeling Tool 24 

by Rashmi Wadhawan 

Security-focused stories: Implementation tips in Agile development environments 26 

by Vishal Asthana & Rohit Sethi 

COLUMN: An Agile Project Startup Week: ‘Evo Start’ 29 

by Tom & Kai Gilb 

Masthead 33 

Picture Credits 33 

Index Of Advertisers 33 


Contents

Editorial Board 

Matt Block 

During my career I have played 

the role of developer, development 

manager, and product 

manager. I have learned what 

development practices and processes 

are critical to the success 

of agile and how to drive that 

adoption process. I have learned just how critical 

and how difficult the Product Owner role is in enabling 

the business to realize the full potential 

agile can bring. Learn more at www.developmentblock.com. 

Plamen Balkanski 

With over 14 years of experience 

in IT, I come from software development 

background and I’ve 

worked in Agile, Scrum/XP and 

Kanban/Lean environments. I 

have been involved in co-organizing 

events for the Agile South 

Coast User Group and ScrumFest.org. I am passionate 

about helping teams, individuals and 

companies discover how to work better together 

and how to continue learning while delivering high 

quality solutions to business problems. 

David Alfaro 

David Alfaro is Certified Scrum 

Professional and Scrum Master 

with many years of experience in 

dedicated Agile (Scrum, Kanban 

and XP, being TDD a practice of 

XP), custom tailor coaching for 

collocated and distributed 

teams, aspiring Agile Programmers, and Scrum- 

Masters and Product Owners. 

David was the first Costa Rican to get training 

and successfully implement Scrum in the country. 

He has been the Scrum promoter in Costa Rica 

since 2007. 

He is founder and board member of the Costa 

Rica Agile User Group. He is a Certified Scrum 

Professional (recognition awarded only to those 

that have proven seasoned experience in Scrum 

implementation and adoption). He is the founder 

of Prontitud. He is the reference speaker regarding 

Agile topics in national conferences. 

José Manuel Beas 

One of the best known agile activists 

in Spain. Over the last 

years, as the first president of 

Agile-Spain (organizers of two 

main conferences every year) 

and co-founder of Agilismo.es 

(promoters of new formulas for 

training professionals, like coding-dojos or backlog 

workshops), Jose Manuel Beas had a significant 

participation in the upgrowth of the Spanish agile 

community. He is also aware of the importance 

of sharing experiences, that is why he also writes 

technical articles in his blog and appears in podcasts, 

webinars and very different professional 

events and even has prologued the first TDD book 

in Spanish. His motto is “leave the knowledge 

where it has to be: among people”. He is also 

helping teams by coaching and mentoring and 

can be found in jmbeas.es or as @jmbeas in Twitter. 

Steve Rogalsky 

Steve Rogalsky gets a thrill out 

of solving problems, working 

with teams, and helping people 

learn and improve. I apply this to 

software development using 

lean and agile techniques as a 

process hacker, coach, analyst, 

tester, developer, speaker, and agile advocate. I 

blog at winnipegagilist.blogspot.com and work at 

protegra.com. 

Steve Smith 

Steve Smith is a software developer 

with a passion for building 

quality software as effectively as 

possible. He’s a Microsoft Regional 

Director and MVP, a frequent 

speaker at developer 

conferences, an author, and a 

trainer. He’s the co-founder of NimblePros.com, 

an agile software studio located in Hudson, Ohio, 

which builds custom software for clients with an 

emphasis on quality and craftsmanship. 


Pat Guariglia 

Pat Guariglia is an agile coach 

for Elegant Agile, Inc. He is certified 

as a PMP with the Project 

Management Institute, a Certified 

Scrum Practitioner (CSP) 

and Certified Scrum Master 

(CSM) with the Scrum Alliance. 

Pat has been leading information technology projects 

and coaching agile teams for the last twelve 

years. Pat continues to champion agile practices 

and Scrum in the Upstate New York and New York 

City areas. He speaks at conferences, seminars 

and holds workshops across the Northeast and 

worldwide. Pat contributes articles to the Scrum- 

Alliance.org web site, is the organizer for the Upstate 

New York Agile User Group, and participates 

in the organization and networking of regional 

northeast US agile groups. 

Zuzanna Sochova 

Zuzanna Sochova is a leader of 

the Czech agile community Agile 

Association – AgilniAsociace. 

com, organizing conferences 

and events and sharing the agile 

experience all around. She 

works as a trainer, consultant 

and coach for software organizations, support 

them in tailoring their agile adoption processes 

to company culture (agile-scrum.com). She regularly 

speaks at international agile conferences. 

She is Managing Director of LOTOFIDEA. 

Dave Rooney 

Dave Rooney is a veteran Agile 

Coach in Ottawa, ON, Canada 

with 25 years industry experience, 

and a Co-founder/Consultant 

with Westboro Systems. He 

has been involved with Agile 

Software Development since 

2000, helping private and public sector organizations 

from pre-funding startups to the Fortune 15 

improve their software delivery process. Dave is 

also a co-founder of the Agile Ottawa Group, and 

an active writer, speaker and advocate of agile 

methods in Canada.

Editorial Board 

Josh Anderson 

Josh Anderson is an Agile Activist 

and Coach located in Raleigh, 

NC. He currently serves as the 

Director of Engineering at 

Aprimo|Teradata. Having spent 

the last decade building and 

leading effective and efficient 

software development teams, Josh brings a 

wealth of experience in areas such as Agile adoption/implementation, 

team building, leadership 

development, attracting/hiring/retaining topnotch 

technologists, and software architecture. 

Josh co-hosts a bi-weekly podcast with fellow Agile 

Methodologist, Bob Galen. Meta-Cast, available 

at www.meta-cast.com, involves discussions covering 

Agile/Scrum, team building, management 

techniques, and various other items that affect 

everyone involved in software development. 

Josh can be reached in various ways: 

Podcast Website: www.meta-cast.com 

Podcast Twitter: @MetaHyphenCast 

Personal Twitter: @nosrednAhsoJ 

Maik Nogens 

Maik works as a testing consultant 

with Díaz & Hilterscheid, 

where he focuses on the agile 

aspects of testing. 

As part of his passion to support 

the profession of testers 

and testing, he is very active in 

many peer and community setups. 

Maik is a co-founder of two international peer 

networks, GATE (German Agile Testing and Exploratory 

Workshop) and PotsLightning (the pre- 

Agile Testing Days event held in Potsdam). In his 

hometown Hamburg he moderates the STUGHH 

(Software Test Usergroup Hamburg) and also 

leads the special interest group “Agility” for the 

ASQF organization in Germany. 

He is a black belt in the Miagi-Do School of Software 

Testing, attended the BBST foundation 

course, is a practicing CAT (Certified Agile Tester) 

trainer, conducts Testing Dojos and runs workshops 

for Kanban, SCRUM and other agile areas. 

Ciaran Kennedy 

Ciaran Kennedy (MSc Technology 

Management, CSM, CSP) 

hails from Dublin and has a huge 

passion for Technology and all 

things Agile. He founded Scrum 

Ireland (www.scrum.ie), a leading 

and free Social Network 

dedicated to Agile IT professionals across the 

globe. With many leading companies and individual 

members including Mike Cohn and Jeff 

Sutherland, Scrum Ireland is growing fast in the 

community. During the day Ciaran runs his own 

Agile Company, Chillistore Technologies Ltd (www. 

chillitech.ie) providing Agile Office Services to leading 

blue chip and high tech innovative start-ups. 

He also does some part time lecturing on Agile 

Project Management in his spare time and has 

been a guest speaker at PMI and Engineer Ireland 

events. 

Roy Maines 

Roy Maines graduated Cum 

Laude from Chapman University 

with a BS Degree in Computer 

Information Systems. With over 

30 years’ experience in the IT 

Technology field, Mr. Maines has 

an extensive background in multiple 

disciplines in Technical Project Management. 

Mr. Maines is a certified Project Management 

Professional (PMP), Certified Scrum Master (CSM) 

and Certified Scrum Professional (CSP). Mr. 

Maines has broad experience supporting the full 

SDLC engineering efforts, Test & Evaluation, Formal 

Information Assurance Certification efforts. 

Mr. Maines has held various technical and Project 

Management positions with a number of fortune 

500 companies including Microsoft Corp, Perot 

Systems, Wachovia Bank NA, and Mantech Systems 

Engineering Corp. Mr. Maines diverse experiences 

enable systematic analysis and troubleshooting 

of large scale technical issues and 

management of key business metrics. 


Declan Whelan 

I strive on building great software 

with great teams. During my career, 

I have found agile/lean 

principles and practices to be 

the best way to do that. So I now 

spend a lot of my energy training, 

coaching and mentoring 

teams to build the environments in which they can 

truly succeed: open, supportive environments 

where everyone brings their genius selves to work 

each day to deliver continuous value. 

Andreas Ebbert-Karroum 

Andreas Ebbert-Karroum leads 

the Agile Software Factory (ASF) 

at codecentric. For more than 

four years, he is a certified 

Scrum Master. Since then he 

could contribute his competencies 

in small and large (> 300 

persons), internal and external, or local and 

global projects as developer, scrum master or 

product owner. Meanwhile, he’s also a Professional 

Developer Scrum Trainer, conducting a 

hands-on training for Scrum team members, 

which codecentric has developed together with 

scrum.org and in which he shares with joy the 

knowledge gained in the ASF. More than 15 years 

ago, his interest in JavaSE/EE awakened, and it 

never vanished since then. His focus at codecentric 

is the continuous improvement of the development 

process in the Agile Software Factory, where 

technical, organizational and social possibilities 

are the challenging, external determining factors.

The Agile Project 

Manager: WIPping 

Things Into Shape 

by Bob Galen 

I once was leading/coaching a team that struggled mightily to 

work together as a team. I was the Director of R&D at an eCommerce 

SaaS product company. We had been leveraging Scrum 

for a number of years with reasonably good success and had 

approximately 10 Scrum teams focusing on the various aspects 

of our online product. 

But there were a couple of teams that were really struggling, which 

often seems to be the nature of things. Out of ten teams, we had 

about three that were high performing, three that were moderately 

performing, and three that struggled along. Don’t get me wrong, 

the team members were solid people and good employees. It was 

just that this whole “agile collaboration thing” was hard for some 

of them to grasp and embrace. 

One particular team truly struggled. They had failed quite a few 

sprints in a row and I was intervening as a coach. Let me digress 

for just a moment on the whole failure thing, before you all start 

throwing tomatoes: 

We measured success or failure not by hours, or points, or stories 

completed. We measured it by the team meeting their Sprint Goal 

that was established when they planned and committed to their 

sprint. There is a lot of angst in the Scrum community over using 

Pass vs. Fail or even using the word “commitment”. For the purposes 

of this article, I do not necessarily want to try and debate 

this practice. You can see references to some related posts at the 

end of the article. Suffice it to say that, at the time of this example, 

we measured and cared about sprints passing versus failing. 

As they failed, they would talk about adjustments in their retrospectives. 

But the modifications were often quite trivial or safe. I felt 

they were not addressing the issues that were truly impacting their 

performance. I remember in one retrospective, they decided that 

the estimation units they were using were flawed. So they moved 

from a modified Fibonacci to Gummy Bears. Needlessly to say, the 

next sprint was not positively influenced by the adjustment. This 

went on for quite some time. 

I am normally a patient coach and I try to influence teams to observe 

and improve on their own. But this team truly was not “getting 

it”. So, after about their fourth or fifth failure in a row, I gathered 

the team’s Scrum Master and Product Owner in my office for a 

“chat”. I insisted that the failure pattern that they were experiencing 

needed to stop. I told them that I felt their root problem was 

that the team was not collaborating on their work. That they were 

operating as a Scrummer-fall based team and that individual work 

was the norm rather than teaming, swarming, collaboration, and 


teamwork. They agreed and they voiced their own frustration with 

the lack of improvement. But they did not know what to do and 

they were reluctant to “tell” the team what to do. 

I quickly suggested two things. But the change had to be theirs. 

If they did not like my adjustment recommendations, then they 

should pick meaningful ones of their own, but they should stop 

dancing around the root challenges and truly attack meaningful 

adjustment ideas in their retrospective. Clearly, something had to 

change – for the team’s sake. 

My Two Adjustments 

I recommended two simple adjustments for their team: 

■ First, I asked them to co-locate or sit together as a team, 

find a place where they could all sit together for one sprint. 

I spoke about the quintessential Agile team environment, 

where everyone sat at a long table – along both sides. The 

entire team residing in a single room, where they could see 

and hear each other and where they would be naturally 

pairing. A room where they could pull away from the laptops 

and gather around a whiteboard and where they could have 

their daily Scrum right there in the same space. 

Could they just try it … for only a 2-week sprint? 

■ Next, I asked them to limit their work-in-progress or WIP. I 

did not necessarily have a “magic number”, but I thought 

that a WIP limit of three might be useful for them. And, as a 

note, this would be a hard limit. The team could only work 

on three user stories in the Sprint Backlog at one time. 

These would be the highest priority stories. In order for 

them to pick-up the next story, they would have to complete 

one of the current three and demonstrate that it met their 

definition of “done”. 

That was it. Two small changes fully targeted at their collaboration 

challenges. 

Well, fast forward past their next retrospective and the team “accepted” 

my recommendations and tried them out. They found a 

large conference room that they took over as a team room and

everyone moved into the room: front-developers, testers, back-end 

developers, Scrum Master and the Product Owner. The whole team 

co-located for a sprint. 

Their sprint planning went on largely as before, but the workflow 

strategies were strongly influenced by the WIP limits. In fact, they 

only planned on attacking the first three stories, leaving the remainder 

of the work to emerge during the sprint. So, they did a bit 

of guessing on how much would fit into the sprint. 

But, importantly, they left sprint planning with a commitment to a 

body of work and a commitment to swarm on their work as a team. 

They were willing to give the adjustments an honest try. 

Results 

I rarely like to use numbers to illustrate results because they can 

be misleading and miss much of the nuance. However, in this case, 

I want to leverage some of the team’s numbers simply because 

it illustrates the impact these modifications had AND the results 

the team realized. 

The team previously would commit to a body of work and deliver 

only 60–75 % of the work (stories) toward their sprint goals. That 

was typical. They also often missed delivering higher priority stories 

over lower priority stories. 

The sprint where they made these two adjustments, the team 

delivered to 140 % of their commitment; pulling more work in than 

they had thought feasible. Not only that, they delivered in priority 

order, so if something had happened they would have delivered 

higher value first. 

But there is even a hidden fact I have left out. It just so happened 

that this team received a new team member a few days before the 

sprint started. While being an experienced engineer, this person 

was totally new to the company, product, and team. As part of the 

team’s renewed focus on collaboration and swarming, they embraced 

the new developer and he actually had a net-net positive 

impact on the sprint’s results. 

What Changes Do WIP Limits Influence? 

Even before Kanban became more popular I was leveraging WIP 

limits in my coaching as an aid to driving collaboration and swarming 

around work. The reality is that when a team swarms around 

their work and removes delays, hand-offs, and inspection points, 

they simply get more done. But it is often hard for some teams 

to realize it. 

Getting back to our team, what did they experience over their 

initial sprint? 

1. The daily Scrum became more of a collaborative planning 

session than a status meeting for the team. The discussions 

surrounded who would work with whom to maximize their 

focus on the limited WIP and effectively working together. 

2. Since the team only had a few things to work on, keeping 

them “flowing” towards completion was important. So any 

delays, impediments, or issues became immediately visible 

and required team-wide adjustments. This helped in getting 

work “done” as well as improving their throughput. 


3. It was funny. Even though they all sat in close proximity, the 

team had not truly collaborated previously. But removing 

all of the walls and getting everyone co-located changed 

the collaborative dynamic. There was much more dynamic 

pairing across team members and natural cross-team communication. 

4. Another aspect of the room was work visualization. There 

was a shared whiteboard where the team had their sprint 

plans. Story and task card movement was incredibly visual 

and the team spent time at the board every day adjusting 

their visualizations for work pairings and workflow. 

5. Quality was better as the developers and testers paired 

more frequently and naturally. They found bugs quickly and 

focused on repairing them rather than talking about or documenting 

them for later resolution. 

6. As I mentioned earlier, the team really did not plan the sprint 

end-to-end in the traditional sense. Instead, they planned 

each new story as they picked it up, changing their collaboration 

as required. It was dynamic, fast, and optimized the 

throughput of the team towards getting things DONE! 

The key conversations in the daily stand-up moved from “What has 

each individual done or what do they plan to do?” to “How does 

the team maximize their daily focus to get the highest priority work 

done as quickly and as well as possible?” 

Wrapping Up 

As for my example team, some might wonder what happened after 

that initial sprint. Did they move back to their old offices? Did they 

change back to their old habits? And did they continue to improve? 

I will leave that answer for another time and another article. 

The real point is – are you struggling to collaborate as a team? 

Are your developers holding on to work too long? Do you have too 

many stories in play at once and miss delivering important work? 

Is Scrummer-fall alive and well in your organization? Or are you 

just not as productive as you think you could be? 

If so, please consider sitting together and limiting your WIP. You 

just might see a different result. ■ 

> about the author 

Bob Galen 

Bob Galen is President & Certified Scrum Coach (CSC) at 

RGCG, LLC a technical consultancy focused towards increasing 

agility and pragmatism within software projects 

and teams. He has over 30 years of experience as a software 

developer, tester, project manager and leader. Bob 

regularly consults, writes, and is a popular speaker on a 

wide variety of software topics. He is also the author of the books: “Agile 

Reflections” and “Scrum Product Ownership”. He can be reached at: 

bob@rgalen.com

Column 

It was a rainy evening. A strong wind was howling outside, but 

inside the aromatic scent of Assam tea was in the air. 

Jack returned home from a tiring day at the office, where he worked 

as a software developer. His friend Lisa, with whom he shared a 

flat, was preparing herself a cup of tea. 

Lisa: Hi Jack, you look like you also need a cup of tea – how 

did you go today? 

Jack: Well – Andrea, a new developer joined my software 

team today. Everybody tried to be nice and friendly and we 

gave her answers to all the questions she had. She seems 

very smart and I think she immediately sensed that our team 

is a special one. 

Lisa: And that kept you from doing your day job, did it? So 

what did she ask? 

Jack: Well, the usual stuff, you know: “When do you start work 

in the morning?”, “What Configuration Management System 

are you using”, “Where can I get coffee?”and so on. 

Lisa: Who is looking after her in the team? 

Jack: Nobody. She has to find her way into the team by herself, 

as we all had to. Hopefully she integrates better than Brian, the 

last new guy who joined the team. He really ran into problems, 

and it took him many months before he finally got along with 

the rest of us. Well, we just have to wait and see, I guess – not 

much we can do. 

Lisa handed Jack a cup of tea and looked at him. 

Lisa: Don’t you think you all have responsibility? 

Jack: Oh come on, we are not her parents – that’s the way 

we always deal with new team members. How was your day? 

Lisa: Nothing special at the clinic, just the usually crazy people 

with their problems. By the way, I bought some bread at Charlys 

bakery on the way back home. You have to try it. 

Jack: Why? Is it different? 

Lisa: I hope so. After I told Charly last week that his bread was 

a bit salty, he decided to change the recipe. So we are trying 

out the new bread now – and he is curious about our opinion. 


By the way… 

by Tanja Schmitz-Remberg & Werner Lieblang 

Jack tried the bread. Indeed, it was much better. He sipped his tea, 

smiled at Lisa and looked out the window. The rain had stopped. 

He took another bite of the bread and was wondering, how Andrea 

would get along with her new team. ■ 

> about the authors 

Tanja Schmitz-Remberg and Werner Lieblang 

Tanja Schmitz-Remberg and Werner Lieblang combine half 

a century of experience in software engineering and training 

various groups. Werner is working as a tester trainer 

and agile coach, Tanja works as a communication and 

group work trainer. 

Being friends for ages and sharing an enthusiasm for 

working with agile groups, they passionately play impro-theatre and love to 

dare out-of-the-box stuff. Together they have developed several trainings for 

members of the agile community.

Enjoy Test Case Design in the Cloud 

CaseMaker SaaS systematically supports test case design by covering the techniques taught 

in the ISTQB ® Certifi ed Tester program and standardized within the British Standard BS 7925. 

The implemented techniques are: Equivalence Partitioning, Boundary Check, Error Guessing, 

Decision Tables and Pairwise Testing. Risk-Based Testing is supported as well. 

CaseMaker SaaS fi ts between 

Requirement Management and 

Test Management/Test Automation. 

Subscribe and try for free! 

Decide afterwards. 

One license starts at 

75 €/month (+ VAT) 

saas.casemaker.eu 

© Pitopia/Klaus-Peter Adler, 2007

Kanban – Quo vadis? 

From Manufacturing to IT companies, where next? 

by Maik Nogens 

Introduction 

Many might know the foundation of Kanban 1 and now also see the 

success stories within the computer industry, from web shops to 

bank applications. Many companies are using Kanban (or “Kanban 

in IT” 2 as it is also known in Germany, to differentiate it from the 

way it is used in manufacturing). 

While attending the “AgileCoachCamp Germany 2012” 3 I first 

heard stories about how people used Scrum and Kanban in their 

daily personal lives. 

Over time, I heard and read more stories from different areas of 

life and also started to use “Personal Kanban”. 

Reasoning 

I think it is interesting to see that something we use in our “business 

life” is also used by people not in any way connected to IT, 

software development, or similar technology-oriented areas. 

This knowledge can support us and make us feel confident that 

all the obstacles we might need to overcome to get Agile methods 

introduced and implemented in companies are worth the effort 

and will pay off. Why? 

Because I believe that Kanban is intuitive to use, easy to start 

with, and reflects life better. 

Because life consists of change and if we do not adjust, then life 

will take care in its own way. 

What is true in “non-business” life (aka real life), also holds true 

in “business life”. 

Think about driving a car. What happens if you do not adjust to a 

changing road situation? 

And businesses which do not adapt to changing market situations 

run this risk, too. 

Personal Kanban 

So what is Personal Kanban? How is it “different” to “Business 

Kanban”? 

1 http://de.wikipedia.org/wiki/Kanban 

2 http://www.amazon.de/Kanban-IT-kontinuierlichen-Verbesserung-schaf- 

fen/dp/3446430598 

3 http://accde12.pbworks.com/w/page/50999558/FrontPage 


Well, basically it is not. It follows the same two principles: 

1. Make your workload visible 

2. Limit your workload in progress 

People can use this concept for their personal life, too. 

They can get an overview of all their tasks which stem from social 

obligations (“I have to go to the in-laws, but I also have to meet 

my buddies and the gardening club”), private tasks (“My wife expects 

the fence to be fixed and the shelf assembled, and I really 

should do the dishes at least twice a week”), work interference 

(“I promised my boss the article next week, plus the client wants 

my attention over dinner”). 

Often the sheer amount of tasks can stun us into inaction or 

procrastination until the deadline looms and we have to REact 

in panic mode. 

Personal experience 

I will the story of how I applied Personal Kanban to a very personal 

project: moving house. 

We had to move house all of a sudden last year. The decision was 

forced on us rather than planned. Furthermore, I was involved in a 

project on the other side of the country and had a full-time week 

there. We managed to secure a house quite quickly and were now 

faced with the Moloch of “moving house”. 

It felt overwhelming and “impossible”. I was using Personal Kanban 

already and decided to make a separate board for this specific 

three-month project. 

Setup 

I put everything on task cards: registration with local authority for 

new house, deregistration with old authority, getting card boxes 

to put stuff in, checking out paint colors and buying paint tools, 

organizing kitchen people to visit and take measurements, getting 

lamps down and stuff dismantled, etc., basically ALL the tasks I 

could think of at that moment. 

My wife and I reflected on the collection and put some more cards 

up where I had overlooked some items. 

What had been an enormous, amorphous, intangible mass, sucking 

out my energy and decision making to get started became a 

tangible, concise, readable list of items (97 in total by the way).

Pattern detection 

Immediately I also saw pattern of dependencies. 

I needed the lamps up in the old house as long as possible, since I 

would need to work in the afternoons when it was dark in Germany. 

Also I could only register after I had already deregistered. 

And, of course, I needed to have card boxes first before I could 

put stuff in. 

So prioritizing and sorting was instantly possible once I could see 

the items. 

We kept the Kanban task board simple enough, so other members 

of the family could use it intuitively. 

We had To-Do, Doing and Done. We put all the cards in To-Do and, 

since we had chosen paper cards, it was easy to reorganize them 

when needed. 

Retrospection 

Every two to three days we would get together and discuss what 

we had done and how the progress was going. I would take over 

a lot of the administrative stuff which I could handle by phone or 

email and where physical location was not important, while my 

wife would do the location-dependent tasks. I would organize the 

appointment with the kitchen people, my wife would be there to 

let them in and be involved in the detailed discussion. 

Tasks were distributed naturally. She had the authority for colors 

and deco stuff; no argument there. 

Adapt to change 

Sometimes life happened and tasks were thrown out or postponed. 

Sometimes we achieved some tasks together, when the opportunity 

arose. (Our local DIY market had a special offer on carpets one day, 

while we were shopping for bathroom cupboards and the carpet 

design found our approval.) 

Conclusion 

Did all the house moving go to budget, plan and time? 

Well, we moved in time and lost none of our stuff. We were somewhat 

over our budget, but it was a conscious decision and not 

because we had no choice. 

We also planned the “big day” when we actually loaded the truck. 

That plan was void in the end. More friends showed up than 

expected and we had all the boxes, etc. on the pavement before 

the truck even showed up. 

Overall I consider it was a success. 

The most calming fact for me was that by having the tasks visible 

and reducing the multitasking of working items, it helped me to 

have a relaxed mental state rather than being overwhelmed, and 

to get into an effective working mode again. 


Could we have had got by with to-do lists? 

My belief is that simple to-do lists would not have reflected the 

dependencies and we might have worked on items which were not 

needed at that moment. Our Kanban board gave us the context, 

to see and decide on these patterns. 

One of the (retrospective) reflections I have learned is that in 

“normal” months I use Personal Kanban in a lenient way, but 

whenever pressure rises in terms of tasks pouring in from multiple 

inputs such as private, social, work, etc., I tend to rely on Personal 

Kanban more. This is a pattern I discovered for myself. 

Future adaption planned 

I also started using Personal Kanban in a mix of short and long 

term projects. For example, when I am organizing the next peer 

workshop I put it on a separate swim lane on the board. This is 

my next adaption experiment. ■ 


Maik Nogens 

Maik works as a testing consultant with Díaz & Hilterscheid, 

where he focuses on the agile aspects of software testing. 

His 19 years of work experience include being a NATO 

naval broadcast team leader in the German Navy HQ and 

a project leader in the Middle East (Bahrain) as well as 

working in software development companies as a tester 

and QA in different industries. 

Since joining Díaz & Hilterscheid, he completed many projects in the banking 

industry, in medical software companies and various agile adaptations. 

These projects range from Kanban implementation and conducting of Testing 

Dojos to the more traditional roles in test management, test infrastructure 

planning and tool support. 

As part of his passion to support the profession of testers and testing, he is 

very active in many peer and community setups. 

Maik is a co-founder of two international peer networks, GATE (German Agile 

Testing and Exploratory Workshop) and PotsLightning (the pre- Agile Testing 

Days event held in Potsdam). In his hometown Hamburg he moderates the 

STUGHH (Software Test Usergroup Hamburg) and also leads the special interest 

group “Agility” for the ASQF organization in Germany. 

He is a black belt in the Miagi-Do School of Software Testing, attended the BBST 

foundation course, is a practicing CAT (Certified Agile Tester) trainer, conducts 

Testing Dojos and runs workshops for Kanban, SCRUM and other agile areas. 

He is a CSM, a CAT and holds the ISTQB Full Advanced Level.

How to create the 

agile enterprise 

by Michael Azoff 

Summary 

The concept of the agile enterprise set out in Ovum’s latest report, 

Agile and Lean Business Transformation, arises from practices 

that embrace common principles and values, such as putting 

uppermost the delivery of value to the customer and high quality 

products. Three areas are explored for creating the agile enterprise: 

innovation, organization management, and IT department 

agility. Large enterprises face challenges on these three fronts. 

First, even the most successful enterprise eventually hits the innovation 

wall and questions how to break through to continue to 

innovate and act as nimbly and creatively as a startup. Second, 

the need to respond to changing market conditions and keep an 

organization’s strategy in touch with these changes is another challenge 

hampered by the annual budgeting process. Third, software 

development has been transformed by Agile methodologies and 

the next step is to transform the whole IT department. Addressing 

each of these areas through Agile practices such as Lean Startup, 

Beyond Budgeting and DevOps can help transform an organization 

and create an agile enterprise. 

Innovation through iterative trials to first identify 

the customer 

Companies must innovate because eventually customers dry up 

and the engine of growth stops. The solution when competing 

against startups is to incubate your own startups within the organization. 

This requires an adaptive organization – one that can adjust 

its processes and performance to meet the challenges arising 

from changing market conditions. Innovation portfolio thinking is 

required for the company to nurture its own disruptive innovations. 

Startup entrepreneurs like Steve Blank and Eric Reis have created 

new innovation models that exploit iterative feedback loops 

and learning based on scientific method (hypothesis, experiment, 

learn), and set within a Lean-style continuous learning framework. 

Most crucially, customer development before product development 

is central to their approach – identify exactly who the customer 

is before spending resources on the product or service. Lean 

Startup and related processes, such as Yammer’s data-driven 

development, act as innovation incubators suitable for startups 

and large enterprises. 

Taking Agile and Lean to the whole IT department 

Agile and Lean thinking have transformed the world of software 

development, and now it is the turn of IT operations to embrace 

agility, through adopting DevOps thinking. Developers need to work 

with operations to create development and test environments that 


remain compliant, while operations need to be able to move at 

the speed of Agile processes to keep developers happy. However, 

often developers do not understand the constraints that exist in 

operations, for example provisioning images is fast but provisioning 

servers can be more complex. So collaboration between the 

old departmental silos and co-defining deployment pipelines can 

help improve the IT operations services offered. 

Transforming organization management through Beyond Budgeting 

Beyond Budgeting (BB) is a management movement supported by 

the BB Round Table, an education network. BB starts by transforming 

the financing process within an enterprise. The annual budget 

cycle (ABC) is a waterfall/big bang effort that has been described 

as “like a bank that opens its doors for only one week in the year”. 

Moreover, the amount of time wasted in satisfying performance 

metrics (linked to the budget promises) that quickly become out 

of step with reality act as a brake on the organization’s ability to 

adapt to new market conditions. 

BB sweeps out ABC and introduces a continuous financing model, 

supported by rolling forecasts, which help ensure the business 

strategy is on track. Annual budget milestones are still met, for 

example to satisfy external compliance needs, but budgets are allocated 

internally whenever required. Management performance is 

assessed on team and peer-to-peer relative performance metrics. 

The incentive for traditional budgets to create walls is removed and 

people within the organization discover a new degree of freedom 

to act in the interests of the organization. 

For example, Statoil, a Norwegian oil and gas giant, has adopted BB 

with dynamic forecasts, where new forecasts are initiated whenever 

market events necessitate a revision. Statoil has also split the ABC 

single budget metric into three separate components: forecasts 

(measured as objectively as possible), targets (designed to stretch 

performance), and resource allocation. The management structure 

is also changed in BB to allow customer-manager relationships to 

drive business, rather than always deferring to the center, so any 

command-and-control culture is reduced. 

Characteristics of an agile enterprise reflect Agile and Lean principles 

Ovum believes that organizations adopting Agile and Lean practices 

in the IT department, BB in the mainstream business, and Lean 

Startup (and related processes) as a driver for innovation, can lead 

to an agile enterprise transformation. Such an organization has 

reduced risk by relying on rapid evaluation of evidence to drive 

business strategy, and uses feedback loops in the IT department 

and the mainstream business to guide activities and deliver what

the customer wants. There are, of course, many paths to becoming 

an agile enterprise but Ovum believes they all approach this goal 

along different sides of the same entity, one which has embraced 

the principles and values of Agile and Lean thinking. 

Some of the practices that Ovum believes are essential to a successful 

agile enterprise transformation are: Agile and Lean software 

development processes in favor of waterfall where possible. 

Although waterfall is still widely practiced and has its uses, there is 

more to be gained from a hybrid or pure Agile approach. Example 

Agile processes are Scrum and Lean development. As a result 

the agile IT department is able to respond quickly to customer 

needs, put working software in front of end users in rapid iterations, 

and incrementally build what the customer needs and will 

use. Furthermore, the business and IT people have regular contact 

with each other, are able to identify who the key stakeholders are, 

and are able to self-organize workshops and planning meetings 

that ensure requirements are captured, accurate, and prioritized. 

DevOps needs to be adopted in IT operations as discussed above. 

Many good practices from the old waterfall regime should be 

retained in the agile enterprise. Corporate and IT governance are 

more important than ever in ensuring that, in a large enterprise, 

senior management is in touch with the edge of the organization, 

that there is transparency of activity to help ensure it is tied to 

corporate strategy, and that decision making is always raised to 

the right level of seniority depending on its impact (without a slow 

License ISTQB ® and IREB ® 

training materials! 

Díaz & Hilterscheid creates and shares ISTQB ® and IREB ® 

training material that provides the resources you need to 

quickly and successfully offer a comprehensive training 

program preparing students for certifi cation. 

Save money and save time by quickly and easily incorporating 

our best practices and training experience into your 

own training. 



10707 Berlin 

Germany 

Phone: +49 (0)30 74 76 28-0 

Fax: +49 (0)30 74 76 28-99 



Page 13 Agile Record – www.agilerecord.com 

and overburdening change process). Risk management is central 

to good governance practices. 

The characteristics of an agile enterprise are reflected in its adherence 

to the principles of Agile and Lean thinking. Some of these 

can be summarized as follows: 

■ Delivering value to the customer. 

■ Creating a set of corporate values that everyone in the 

organization believes in and follows. 

■ Creating teams that function through macro-management 

and that are accountable for their performance at a team 

level. 

■ Creating fast feedback processes to ensure that customer 

value is being created and not waste. ‘Fail fast’ is the principle 

that ensures the correct course is chosen by eliminating 

bad paths as quickly as possible. 

■ Continuous learning ensures that the organization is able 

to adapt to changes and is improving its performance. 

■ Change is normal – the ability to be flexible with moving 

project requirements is a mark of agility. 

■ The art of maximizing the amount of work not done – in 

tune with waste reduction and an emphasis on good prioritization 

of effort. 

Our material consists of PowerPoint presentations 

and exercises in the latest versions available. 

Our special plus: we offer our material in four different 

languages: English, German, Spanish and French. 

For pricing information and other product licensing requests, please contact us either by phone or e-mail.

■ Lean principles of just-in-time are introduced where appropriate, 

with the aim of achieving a continuous flow of work. 

■ From Beyond Budgeting: individuals are rewarded on relative 

peer-to-peer performance and not short-term fixed 

targets. This helps ensure that ambitious goals can be 

created. 

The biggest barrier to change is organizational culture, but, given 

the will to change by the board of directors and senior management, 

such barriers can be overcome. There will be different degrees of 

agility as an organization aims for improvement. A maturity model 

such as depicted in Figure 1 shows the possible approaches in 

terms of three categories: core agile team activity (intra-team 

agility); business-to-IT team agility (outer-team agility); and agility 

across the whole organization, where the IT department is not 

detached from the business but is intimately tied to it (business 

agility). 

The first step in this maturity model is to fix any broken processes 

in the IT department and achieve intra-team agility where development 

is done by agile teams and can achieve proven successes. 

Intra-team agility is possible even with minimal involvement from 

the business and is ideal for keeping the basic IT needs of the 

organization running, and where projects are tactical in nature. 

The next stage is good IT department engagement with the rest 

of the business (a feature of Agile methodologies like Scrum and 

Extreme Programming), and represents involvement of product 

owners, user acceptance testing after each iteration, and plenty 

of face-to-face dialogues with business stakeholders. IT projects 

now extend to differentiators and innovators as IT people are 

now engaged in business thinking and strategy aspirations. The 

ultimate goal is business agility, where the mainstream business 

processes have adopted Agile ways of working and where IT use is 

optimized, from ‘run the business’ to innovation, and from tactical 

requirements to long-term strategic requirements affecting the 

future of the business. 

Strategic 

Tactical 

Intra-Team 

Agility 

Keep the 

business running 

Business Agility 

Outer-Team Agility 

Figure 1: Organization agility maturity model (source: Ovum) 

Differentiation, 

Innovation 


It can happen that the IT department becomes engaged at any 

point on the map in Figure 1 without being agile. The point is that 

unless IT and business teams adopt Agile and Lean ways of working, 

the results are going to be hit and miss (as has been the case 

with waterfall). The correct way to interpret Figure 1 is as a guide 

to the degrees of agility necessary in the organization to achieve 

repeatable success at the level required: tactical or strategic, run 

the business, or change the business. 

Appendix 

Further reading 

■ Ovum Analyst Insight report: Agile and Lean Business 

Transformation, Michael Azoff, Jan 2013. 

■ Ovum Analyst Insight: Managing large-scale agile projects: 

case studies, Oct 2012, IT016-001469. 

■ Ovum Analyst Insight: Agile in the UK public sector, Oct 

2012, IT016-001468. 

■ Ovum Analyst Insight report: Agile Thinking Is the Key to ICT 

Project Success, Jan 2012, IT007-000604. 

■ Ovum Solution Guide: DevOps: Advances in Release Management 

and Automation, Sep 2011, IT017-003564. 

■ Ovum Analyst Insight: DevOps: Agile Operations and Continuous 

Delivery, Sep 2011, IT017-003561. 

■ Steven Gary Blank, The Four Steps to the Epiphany, Cafepress, 

2nd edition 2006. 

■ Bjarte Bogsnes, Implementing Beyond Budgeting: Unlocking 

the Performance Potential, J Wiley, 2008. 

■ Jeremy Hope and Robin Fraser, Beyond Budgeting, Harvard 

Business School Press, 2003. 

■ Jeremy Hope, Peter Bunce, Franz Roosli, The Leader’s Dilemma: 

How to Build an Empowered and Adaptive Organization 

without Losing Control, J Wiley, 2011. 

■ Eric Reis, The Lean Startup, Portfolio Penguin, 2011. ■ 


Michael Azoff 

Michael Azoff (PhD, MIEEE) has been working as an IT 

industry analyst since 2003, bringing over 20 years of 

experience in pure and applied research and consulting 

in the IT industry. At Ovum he leads the software development 

and lifecycle management (SDLM) research and his 

current focus is on Agile and Lean practices in software 

development, including enterprise agile transformation initiatives, DevOps, 

cloud-related SDLM, application performance management, and enterprise 

IT mobile development.

Column 

Agile is not something you do, it is something you are. With that 

in mind, I started working at codecentric. A passionate company 

that not only helps customers to implement agile methodologies, 

but also helps the same customers to be agile, at all levels of the 

organization. We are self-steering, our processes are visual and 

transparent and are periodic ‘geretrospectived’ to learn from the 

past to improve. 

If you work for an organization that is trying to get agility across to 

customers, why not extended it to the rest of my life? A joke goes 

around about applying agile in your private life: “You can easily 

use Scrum at home, but I wouldn’t recommend it! You will find 

out very quickly who is the Product Owner, and it’s not you …”. 

With that sage advice in mind, I started searching how I can apply 

more agile principles in my everyday life. At Potslightning, the peer 

conference before Agile Testing Days 2012, I was introduced to 

“Personal Kanban” by Meike Mertsch 1 . 

Personal Kanban is not to be confused with the original Kanban 

as developed and applied successfully by Toyota. And it isn’t the 

software development technique to quickly and as effectively as 

possible meet customer demand in a team. I am talking about a 

real personal variation. It is based on the same principles as the 

original: 

■ The starting point is: I want to create value (not finish premade 

checklists) 

■ I want to get as much flow as possible in the things I do 

The rules are deceptively simple 2 : visualize what you do and put 

a limit on the work in progress. 

I am easily distracted and have a tendency to take on too many 

things at once. I’m also an eternal optimist and structurally plan 

not enough time to get things done. Finally I have trouble saying 

no when fun or interesting things pass by. So when Meike told me 

about personal Kanban I tought that could help me too…. 

For me personal kanban works better than finishing various 

tasklists. These have a tendency to become especially large and 

I can’t do the tasks from top to bottom. In a tasklist you can’t or 

1 http://agiletester.webnode.com/news/personal-kanban-to-my-rescue1/ 

2 http://www.personalkanban.com 

Creating my own flow 

with personal kanban 


by Huib Schoots 

only poorly see where you currently are working on, not to mention 

that it shows how many things you actually doing simultaneously. 

And in my case that is often too much. The list doesn’t help me 

actually to get all those things done. The tasklist can ultimately 

only help me afterwards to make sure everything is done. It does 

not help to support the process to actually do anything. 

And that is precisely what visualization does! By defining a simple 

process and visualizing it, suddenly it becomes (painfully) clear 

what the real progress is. By defining a clear limit for the work in 

progress it might become painfully clear that it will be very difficult 

to fulfill all those nice promises you made so casually within 

a reasonable time. And that’s a big advantage of Kanban in your 

daily live: you can start measuring how many of those promises you 

can handle per day, week or month. So now you can finally see if 

that commitment you made to your partner to do a particular job 

tomorrow is real. And that will prevent a lot of course. 

This is my personal Kanban board:

In the meantime I have been using it for a few weeks now and I 

feel I have more grip on what I’m doing. I still have to force myself 

to keep using the board and I am still not fully satisfied, but it 

really helps me. 

I have my kanban board always with me because I keep it in my 

note book. I started with two separate boards: private workitems 

(top) and a work-related (bottom). In the meanwhile I have put 

them together. The work I do for clients during office hours is not 

on my board. The both boards were actually competing for the 

same timeslots. So it was not very logical to keep two boards. 

I will keep experimenting with my board and it is likely that I will 

change my board or the process in the near future. If I can buy 

the right size, I might consider using multiple colored stickies. Or 

try an extra lane “queue” on the board. Time will tell. ■ 

Do you want to write an article for 

the next Agile Record? 

If you would like to participate in the next issue, please complete 

the following steps: 

1. Download the Microsoft Word template from our website and 

complete it, including a short biography of the author(s). 

2. Submit your finished article to our online system, after which 

our editorial board will rate it and our editor José Díaz will 

accept or reject it. 

3. If your article is accepted, we will contact you and ask you to 

send the figures and pictures to be included in the article in the 

highest resolution you can provide (72 DPI for screenshots, 300 

DPI minimum for all other image files), as well as the photo(s) 

of the author(s) to editorial@agilerecord.com. 

4. Download the consent form (PDF) from our website and sign it, 

scan it and send it to editorial@agilerecord.com. If an article 

was written by several authors, all of them have to sign the 

consent form individually. 

5. After your article has been reviewed for spelling and grammar 

and has been returned to you, you accept or reject the changes. 



Huib Schoots 

Huib Schoots is currently an agile test consultant at codecentric 

where he shares his passion for testing and agile 

through coaching, training and giving presentations on a 

variety of subjects. With fifteen years of experience in IT 

and software testing, Huib is experienced in different testing 

roles. Curious and passionate, he is an agile and 

context-driven tester who attempts to read everything ever published on software 

testing. A member of the Dutch Exploratory Workshop on Testing, blackbelt 

in the Miagi-Do School of software testing and coauthor of a book about 

the future of software testing. Huib maintains a blog on magnifiant.com. 

Note: 

■ Please take care of copyrights and registered trademarks. 

■ We do not accept sales pitches advertising a product or 

company. 

■ Your article must not have been published before. 

■ There will be no remuneration. 

Agile Record schedule 

Issue Deadline for Articles Topic 

No. 14 (May 2013) April 1, 2013 “Agile adoption stories – 

What Worked and What 

Didn’t” 

No. 15 (Aug 2013) July 1, 2013 “Distributed Team 

Management” 

No. 16 (Nov 2013) October 1, 2013 “Refactoring” 

www.agilerecord.com 

For any questions please email us at editorial@agilerecord.com.

The Day Dan Realized 

the Power of Kanban! 

by Raja Bavani 

Introduction 

Adoption of new methods or techniques is a learning experience. 

Project teams adopt new methods or techniques either deliberately 

or accidentally. Accidental adoption can happen because of difficult 

circumstances or unexpected events induced by factors such as 

an unexpected spurt of changes in requirements, issues related 

to product quality, and so on. During such circumstances, one may 

introduce changes to current set of processes or techniques and 

later realize that the new way or approach resembled a popular 

process or technique. Once, Dan and his team members went 

through this experience in their professional life. This article about 

Dan is based on a real life experience. 

Dan’s Delight 

On Monday after the Labor Day weekend of 2002, Dan was on top 

of the world because Tom, his boss, assigned him one of the most 

technically challenging projects in the company. Tom was the IT 

director of a large manufacturing company that supplied electronic 

utilities to households through retail outlets. Dan was one of his 

direct reports who played the role of project manager in IT projects. 

This project, named DA (disconnected access), was about enabling 

their technical support team through a state-of-the-art application 

to support disconnected access to their central databases. Using 

this application, their support team could reach end users living 

in remote areas, provide them with necessary support, collect payment, 

and print invoices even if there was no connectivity to central 

servers. The goal was to improve customer satisfaction and this 

was one of the strategic projects of the year under the CEO’s radar. 

Customer Confidence 

Dan and his team of four engineers studied the high level requirements, 

analyzed the pros and cons of three different architectures, 

and selected the most optimal one. Considering the business 

demand and the estimates, they agreed to deliver the application 

in three months. Alicia was the point-of-contact in the business 

and she had worked with Dan on a different project a year ago. 

She had more than fifteen years of experience in her domain. In 

project DA, she worked closely with Dan and his team in creating 

and reviewing the user interface design during the initial weeks. 

She was happy with the suggestions and ideas from Dan and his 

team and was confident that the team would deliver results. 

Iterative Approach 


Dan believed in an iterative approach and decided with his team 

to execute this project in five iterations of two weeks each. As the 

application incrementally evolved over these five iterations, and 

the schedule was aggressive, Dan could not demonstrate the finished 

product to Alicia before the end of the fourth iteration. Alicia 

had also invited three customer support managers from different 

regions to attend the demo. 

Delayed Demo 

No wonder, in each step of the demo, Alicia and the customer 

support managers started discussing new options and asking 

Dan whether the user interaction can be improved further. They 

suggested new ideas which turned into changes to the user interface 

or validation aspects. After a two-hour demo, Dan and his 

team came out with a list of 50 items, some of which were new 

features, some others were changes, and the rest were cosmetic 

changes and defects. 

The Aftermath 

Dan had a suggestion – that Alicia and her three managers plan 

a one-week acceptance testing after feature completion in order 

to explore all the features and provide him with their feedback. 

Alicia agreed. After a week of acceptance testing Dan’s list had 

more than 275 items. Alicia was not happy with the results and 

Tom, Dan’s boss, was shocked. Dan’s team was distressed that, in 

spite of their sincere efforts, they had to manage this escalation. 

Joint Response 

Tom, Dan, and Alicia had an emergency meeting to discuss the 

situation. The question in front of them was about prioritizing 

and closing all items in a timely manner in such a way that they: 

a) Address high priority items first and move on 

b) Optimize by grouping related items 

c) Test adequately to avoid failure 

d) Understand daily progress and make course correction 

e) Maximize the number of items closed per week through 

weekly analysis

Visualizing the Workflow 

In his discussion with Tom, Dan stressed on the need to create a 

visualized workflow using a white board in a common room or work 

area – even though Tom was against booking a room exclusively for 

his team. Tom believed in electronic communication, bug tracking 

tools, and daily status emails. Dan shared his experience on how 

emails and outdated tools can diminish team work and cause 

delays. Finally Tom agreed. 

The next day, Dan came in early, took a hard copy of prioritized 

work items, and created a visual board in the meeting room. His 

team members helped him with their ideas. They created about 

40 rows on the board and divided each row into multiple columns. 

Each column corresponded to the standard work flow – analyze, 

code, test, verify, build, user acceptance, done. Each row represented 

a work item with a work item identification number, short 

description, and other such attributes. 

The Pull Factor 

From that day onwards, Dan and his team would begin their work 

day with a crisp meeting in front of the white board. They also 

ended their work days by reviewing the items on the white board 

and discussing ways to improve throughput and quality in future. 

During the first few days, Dan was orchestrating the team on task 


assignment. Mostly he was pushing work items or directing his 

team members. Gradually his team started not only pulling work 

items, but also logically grouping work items in order to optimize 

the time spent in coding and testing. Dan appreciated the level of 

ownership, commitment, and team work among his team members. 

Limiting Work in Progress 

Based on his experience, Dan believed that mindless contextswitching 

is a waste of time. This happens as a result of keeping 

many items open, switching back and forth, and losing focus. He 

coached his team to complete as many tasks on hand as possible 

before moving on to the next work item. He also shared with them 

the ill effects of keeping several work-in-progress items. His team 

members grasped the truth behind his suggestions. 

Collaborative Learning 

During these tough weeks, every daily meeting or weekly retrospective 

was a learning experience. Team members shared debugging 

techniques, domain-specific issues, etc. with the rest of the team 

to enrich their knowledge and prevent similar issues. Even during 

the first week they found ways to minimize the number of defects 

by discussing and implementing simple techniques to improve 

quality in each step of the workflow.

The Outcome 

Eventually, Dan’s team became faster and smarter. Dan could see 

an increasing trend in the completion of work items. Seeing these 

positive signs, Alicia regained her trust. Within four weeks, the list 

of pending items had shrunk to 20. 

By the end of the fifth week, they only had ten low priority issues 

on hand. With a schedule overrun of about 6 weeks, Alicia certified 

the application for user training and implementation. 

Reflection and Recognition 

A week after the initiation of user training, Tom and Alicia sponsored 

a dinner for Dan and his team. On the dinner day, Dan convened 

a 30-minute retrospective with his team. Alicia, Dan, and his team 

discussed several aspects of the project including what went well, 

lessons learned, and areas of improvement. Everyone agreed that 

as soon as they came across innumerable changes and new work 

items they worked together to find a new approach and it helped 

them take charge of the situation. The key factors that enabled 

them deliver results were: 

1. Visualizing Workflow 

2. Limiting Work-in-Progress and Minimizing 

3. Context-Switching 

4. Measuring and Managing Flow 

5. Nurturing an Open Environment and Making Processes and 

Policies Explicit 

6. Identifying Improvement Opportunities 

Both Alicia and Dan agreed that they needed to consider demos 

to end users and retrospectives at the end of iterations in their 

projects in order to minimize the spurt of changes and ideas at 

project completion. 

Kanban Knowhow 

Years after this incident Dan reads an article titled ‘Introduction 

to Kanban” and later attends a Kanban workshop. He is able to 

relate the content of the article and the knowledge acquired from 

the Kanban workshop to his project experience. There are many 

similarities and some improvement ideas. He feels proud of himself 

and his team and shares his thoughts with his team mates. He feels 

proud because he can connect with the essence of Kanban in his 

approach. He feels proud because his experience and knowledge 

make him realize the power of Kanban! 

With hindsight, he feels that he could have used yellow stickers 

or a tool to improve effectiveness and optimized the time spent 

managing the visual board. He could have hired a Kanban coach 

to help his team in areas such as value stream mapping. However, 

he realizes that the popularity of Kanban in the software industry 

has grown only in recent years. 

Six months after these happenings and with a promotion at work, 

Dan continues to execute projects using Agile, Lean and Kanban. 

Takeaways 


As I said at the beginning of this article, adopting new methods or 

techniques is a learning experience. I am sure some of you can 

connect with Dan’s experience. Others must have gone through 

the journey of planned adoption. For the rest, it is not too late to 

initiate the practice of Kanban. It works perfectly on maintenance, 

support, and system administration projects. With some experience, 

you will be able to apply Kanban concepts to development 

projects too! ■ 


Raja Bavani 

Raja Bavani is Chief Architect of Mindtree’s Product Engineering 

Services (PES) and IT Services (ITS) groups and 

plays the role of Agile Evangelist. He has more than 20 

years of experience in the IT industry and has published 

papers at international conferences on topics related to 

code quality, distributed Agile, customer value management, 

and software estimation. He is a member of IEEE and IEEE Computer 

Society. He regularly interfaces with educational institutions to offer guest 

lectures and writes for technical conferences. He writes for magazines such 

as Agile Record, Cutter IT Journal, IEEE Software and SD Times. 

His distributed Agile blog posts, articles, and white papers are available at 

www.blogs.mindtree.com/author/raja-bavani and www.se-thoughtograph. 

blogspot.in. He can be reached at raja_bavani@mindtree.com.

The Kanbanist’s Guide to 

the Galaxy 

A software development project run across multiple sites and 

time zones and executed by a non-exclusively dedicated team is 

reminiscent of a spaceship with the indefinite improbability drive. 

For those readers who are not familiar with it, this invention was 

originally described in Douglas Adams’ novel ‘A Hitchhiker’s Guide 

to the Galaxy’. While travelling with such a drive, a vehicle is literally 

everywhere, in the whole Universe at the same time, materializing 

later somewhere, hopefully at its destination, in a better or worse 

shape. From my observations, a similar situation is also true for 

some software development projects. Everyone is busy and many 

people are working on the same thing at the same time, unfortunately 

sometimes pulling it in a direction known only to them. We 

cannot totally protect our work from variability and changes, but 

maybe we can help ourselves to understand the chaos by turning 

thought work into tangible work? 

Kanban: method, board and flow 

Do you know how the characters in the novel were searching for 

knowledge about the crazy surrounding Universe? There was a 

book, today you would say an e-book reader, which acted as a 

special kind of guide. It was a source of useful information accessible 

exactly when needed. It was written by practitioners who 

travelled across the Galaxy themselves, instead of some masters 

of miraculous theory. Do you think such a book exists for Agile 

project management? If so, I bet instead of ‘Don’t Panic!’ it would 

have something about Kanban on the cover. 

This article is not going to be a short version of such a book and 

I am not going to try to convince anybody that apples are better 

than pears. What I will try to do is describe a few real life situations 

and write a little bit on how they address the core principles and 

properties of the Kanban method described initially by David J. 

Anderson. It is up to you what you do with it. 

When you travel through outer space, you have to bear in mind the 

need to obey local laws. Working with a new team and working on 

a new project can make you feel like you are visiting a new planet 

because they have their own language and habits. It happened to 

me when I worked with a distributed team where I had the pleasure 

and enjoyment of proposing we use the Kanban method. First, I 

had separate talks with two parts of the same project team. One 


part of the team was focused on development, the other mostly on 

testing. It does not sound too Agile, does it? To make it harder, they 

worked mostly in geographically separated teams. Conversations 

with developers were quite short and straightforward. Not that that 

was surprising. They consisted of “This is where our work comes 

from, this is how we do it, this is the point in time when we are done” 

and that was all. Conversations with the other team that included 

the testers were much longer. There was a map of the work they had 

done before and after coding, a list of the most common problems, 

plus a few more points. At the end of our conversations, I was able 

to sketch a map of the flow which I subsequently redrew into a 

Kanban board layout. Was it optimal? No. Could it be improved? 

Yes. Did I do anything about it? Not immediately. Why? Because 

you apply Kanban to what you already have. You do not start with 

a revolution, but you need to know where to start an evolution. 

You do not come with a command and control attitude. You do not 

change titles or point a finger at what is wrong on day one. Have 

you ever seen such an approach actually work? 

What I have learned with Kanban, and what was obviously happening 

again, is that respecting the existing process is much more 

important in getting buy-in than any promises. And this is one of 

the key principles of the Kanban method. So, what happened 

next? I heard: “No, we definitely don’t need so many columns!” or 

“What are those buffers for in a team as small as ours?” To their 

surprise, I did not add any additional steps to the existing process. 

On the other hand, the team was partially right – the flow needed 

to be simplified, but just step by step. 

Visualization 

by Radoslaw Orszewski 

As a result of those discussions we created a trail of what was 

actually going on. We could focus on a board and observe. 

Have you noticed software is rather like air? We use it, but we 

basically cannot see it. It is not much different to the work we put 

into it. We know it has been done by using it rather than actually 

seeing the code. The idea of representing an intellectual work by 

sticky notes may sound silly, but it works. Visualizing work items, 

moving them across the board, and being personally responsible 

and attached to a piece of paper can change a lot. A white board 

and post-its, or a proper electronic tool, can show you what has

happened, what is going on, and what will happen next – all of it, no 

matter whether your team is separated by kilometers or light years. 

There are many types of information you can read from a board 

without generating any queries or inventing super-complex KPIs. 

You know exactly what is in progress, i.e. in preparation, development, 

testing, or delivery. What is waiting in some buffer. Who is 

busy with what, and who is waiting for others to finish. You can 

see all of it after just a short glance at the board, if you know and 

understand its meaning and mechanics. No matter whether you 

are a manager or a specialist with just a few hours to share with a 

team, by reading the board you can save a lot of everyone’s time 

by answering the questions you have. The presence of the board 

should by no means stop you from having a discussion with the 

team. Instead, it should trigger the right discussion. We naturally 

move from saying how busy we are to explaining what we have 

accomplished and what is happening on particular tasks. 

Imagine a team of four who are working on the same piece of software. 

There is a senior person as well as newbies and they have 

a good tool for code review. I am sure you know how important a 

proper code review is in terms of quality. Still, I have seen it done 

really badly and really well. Giving someone’s code a minus in a 

tool happens every now and then. Not a big deal, you may say. 

But the perspective changes once you need to re-glue your tickets 

right to left, against the natural and desired flow. Kanban does 

not leave you alone with your problem. It raises team awareness 

that something is wrong. With regular talks in front of the board, 

things change even more and go deeper. There are multi-level 

‘why’ questions. First, the team discusses what is wrong on the 

surface with a short brainstorm of how to do it better, so the code 

is corrected. There is also a lesson behind it for everyone involved 

in a conversation. Instead of shame, disgrace, or criticism, we are 

willing to do it better next time. In the end, the developer and the 

whole team are relieved when the ticket moves from left to right, 

with only pluses from their colleagues. 

WIP limit comes into play 

The Universe is full of stunning creatures and species. For instance, 

there are developers looking at a code and managers talking in the 

language of KPIs. Some planets may be a habitat for humanoids 

with highly functioning multithreading brains or two heads. Who 

knows what else? Certainly, multitasking is not something that 

the human brain likes doing. 

Personally and professionally you need to finish a lot of work, not 

only start it, and, therefore, one more core Kanban rule is very 

important. This is the need to limit the “work-in-progress”, or WIP. 

But wait! Were we not told so many times that working in a truly 

Agile way means many things happening simultaneously? Coding 

and writing a specification, or testing and talking to our customer. 

That is all true, but do not mix things up. It does not mean that one 

person should focus on many points at the same time. 

Limiting WIP not only allows people to focus on the right things, but 

also assures all necessary things will be done with a built-in quality. 

You may think you are able to write a new code and fix totally 

different issues at the same time. Yes, you may think so, and even 

try it. However, if you looked more closely once you had finished, 


you would realize that either the quality had suffered or it had 

taken you much longer than if you had done the tasks one by one. 

How do I set WIP limits? You need to try it first. Take a look at the 

board, ask others, and think about which columns should be addressed 

first. Let initial WIP values be one of your first experiments. 

Actually, one of the big Kanban practice hints is experimenting with 

limiting work in progress. It should be flexible, but you should not 

set it so high that you are always below it. Cheating yourself and 

reality is no solution. Limits need to be adaptable and reflect reality 

– the needs of the team and project – and not just be another 

obstacle in your way. 

Limiting WIP also has another side to it. Limits give positive reinforcement 

to the team to unlock bottlenecks and gather around 

issues to find a root cause and a solution. I do not mean pushing 

a task, but rather looking for a way to be able to pull a task down 

a value stream. 

For instance, I like mountain biking. Despite what my wife would 

say, I do not enjoy cleaning my bike afterwards. The fact is that it 

just needs to be done if you want to enjoy your next ride and before 

you do next enjoyable task. The same applies to some project 

chores. Of course it is more fun to create something new than to 

review others’ code. However, it does not alter the fact that it still 

needs to be done. If you apply a WIP limit to a buffer and a column 

of active code review, the team will need to work on exploiting a 

bottleneck. It ensures the job will be done fully and properly, and 

that people are able pull the next tasks whenever they are ready. 

Observe and optimize 

Travelling across space and time can be tricky. What appears to 

be the best, maybe easiest or shortest, way changes its meaning 

when we are not using a traditional 2-D map, but we are navigating 

across 3-D space. Add time as one more variable and things get 

even more complex. A spaceship, driven by the indefinite improbability 

drive, returns to reality by restoring normality. What would 

this mean in terms of development? 

How about describing normality as a predictable and stable flow 

of work? No supersonic hiccups. No jumps from being lost in a 

swarm of asteroids to hyper-speed jumps. It may appear great 

that, after a few days of no progress, someone delivers 14 different 

fixes. It is not so cool if it happens on a Friday evening, or 

just before some people wanted to leave early to watch a game. 

Would it not be easier for them to digest it more slowly instead of 

being hit with late deliverables? Both rules described above, i.e. 

visualization and limiting WIP, can help you observe, predict, and 

adapt to changes in work flow. 

Clear rules 

I have already mentioned the importance of obeying local laws. 

You may be surprised, but even on your own home planet there 

are places where some activities that seem normal to you can be 

controversial, if not banned. The same may happen in your very 

own office. How do you know what is OK and what is not? Kanban 

strongly suggests clear rules, or rather policies, about process and 

flow. Clear means explicit and known to everyone who is interested.

It is not new in the Agile and Lean worlds. We all know what the 

definition of “done” is, or what old-fashioned quality gates are. 

Some checkpoints tell us that “done” is done, that the quality is 

OK, whether we can proceed or not. Kanban warmly welcomes all 

those kinds of solutions, at least as an initial set up, and forces us 

to analyze whether they make sense and bring value. Of course, 

policies may mean codifying bad practices, but Kanban practice 

can help you identify them really quickly as a source of waste. It 

is the whole team who are empowered to ask questions, or to say 

”no” or ”stop” out loud if they see something wrong going on. As 

you can imagine, having clearly defined and easily accessible rules 

of work makes it is easier for interstellar mercenaries (or freelance 

developers) to join your troop and adopt good habits. 

Destination: planet Kaizen 

Now we have some hints about the board and stickies and some 

rules to follow – is that all? No. What is left for your team to 

discover is the indefinite amount of small steps forward, tiny but 

measurable improvements, which can make your work easier and 

more pleasant. You have reached your destination – Kaizen, or 

continuous improvement if you like. This is just the beginning of 

another long road. 

If the examples described above sound familiar, there is a high 

probability you may find Kanban helpful. It brings people together 

around problems to analyze and solve them. It is a team approach 


and, therefore, can be fun, full of experimenting and learning. A 

superficially linear board and a few simple rules can be very useful 

in navigating your work through a multi-dimensional Cosmos. 

Believe me. Or, better, don’t. Try it yourself! 

The article above has been inspired by a series of science-fiction 

novels written by Douglas Adams – ‘The Hitchhiker’s Guide to the 

Galaxy’, a book ‘Kanban’ by David J. Anderson, and observations 

of everyday life. 42. ■ 


Radoslaw Orszewski 

Radoslaw Orszewski holds a Master of Science degree in 

Biotechnology from Wroclaw University of Technology. After 

graduating, he decided to follow a path as a professional 

software tester and worked in distributed teams on 

mobile software and web travel applications (Sabre Holdings). 

For over 3 years he worked at Nokia on locationbased 

services where he specialized in Agile methodologies (Kanban, Scrum – 

CSM, CSPO, CSP) for project management. Currently based in Berlin, he works 

as an Agile Process & Testing Manager at Skrill (Moneybookers). In his spare 

time he enjoys cycling and writes articles for the largest Polish biking monthly 

magazine.

© iStockphoto.com/davidnay 

Course Details: 

The three-day training course “IREB ® 

Certifi ed Professional for Requirements 

Engineering” is given by Díaz & Hilterscheid 

in German and English and can 

be completed with an independent 

certifi cation exam. 

Incomplete or inconsistent requirements 

engineering leaves scope for interpretation 

in software development and 

makes verifi cation and validation diffi - 

cult. Corrections during the project can 

have serious consequences on time and 

cost planning. 

The training introduces you to the correct 

and complete capture, documentation, 

checking and administration 

of requirements. You will become acquainted 

with procedures, techniques 

and tools and will shown the fundamentals 

of communication theory. The training 

is based on the independent syllabus 

of the International Requirements Engineering 

Board (IREB ® ). 

Follow me @vanTesting 

Prof. van Testing 

recommends 

IREB ® Certified Professional for Requirements Engineering 


Target Audience: 

The training is intended for requirements 

managers, project managers, quality 

managers, software testers and software 

developers who preferably have 

experience in IT projects and some initial 

experience with the handling of requirements. 

Requirements: 

For more information, please visit our website 

or contact us: 

Information regarding the required 

knowledge can be found in the IREB ® syllabus, 

which can be downloaded from 

the IREB ® website: www.certifi ed-re.com. 

In-house Training: 

All of our courses are available as private/in-house 

training. Please contact 

us for details. 



10707 Berlin 

Germany 

Phone: +49 (0)30 74 76 28-0 

Fax: +49 (0)30 74 76 28-99 




Dates: 

19.–21.03.13 Berlin, Germany (DE) 

19.–21.03.13 Oslo, Norway (EN) 

23.–25.04.13 Mödling, Österreich (DE) 


14.–16.05.13 Helsinki, Finland (EN) 


Please note that training dates are subject to change. 

© iStockphoto.com/numbeos

Cumulative Flow Diagram – 

Kanban Predictive Modeling Tool 

by Rashmi Wadhawan 

Are you a manager or business stakeholder working on an Agile 

Scrum Project and facing the following issues? 

■ Team is reporting 80 % complete but not a single feature is 

completely ready for acceptance by client. 

■ Team is saying that they will be able to release within the 

stipulated release plan of three months but you have apprehensions 

about their claim. 

■ You have a strong feeling that there are bottlenecks in the 

process but are facing a lot of difficulty in mapping it to the 

process. 

■ You are not satisfied with the burn-up and burn-down 

charts produced by the team and are interested in getting 

more insight into the process. 

There is a panacea to solve all of the above issues. The name of 

the magic potion is “cumulative flow diagram”. Cumulative flow 

diagrams (CFDs) applied on top of the basic principles of KAN 

(visual) + Ban (card) can give you an insight into the project and 

keep everyone updated. CFD can be an extremely powerful tool 

when applied to a Scrum model. 

Multi-color CFDS look complicated but pretty. The pain of understanding 

it is worth the gain you get from it. These diagrams can 

help you in making critical business decisions. They will help give 

you better visibility regarding the time to market dates for features. 

Applying it on top of a Scrum project will help you see an accurate 

picture of the progress on your project. 

Story Points 

20 

15 

10 

5 

0 

Figure 1 

Week 0 

Week 1 

Week 2 

Timeline 

Week 3 

Week 4 

New 

WIP 

Done 

Let us try to take an overview of the work of an Agile Scrum team 

with a 4-week sprint cycle using CFD. Creating a simple CFD with 

only three states, i.e. Not Started, In Progress and Done, for the 

team shows there were 20 story points in the sprint backlog. Story 


points are the unit of measure used by this team for estimation 

purposes. 

The team was able to finish 19 out of the 20 story points designated 

for the sprint. But the problem with the project was a pattern for 

completion in the shape of a hockey stick. There was no visibility 

until Week 3 about whether the team would be able to meet its 

target and only 4 out of 20 story points were complete by the end 

of Week 3. 

Giving CFD to this team will help them in following the “Inspect 

and Adapt” Scrum principle. They can further zoom into the work 

in progress to see various flow states. 

CFD will help you in analyzing the actual progress and bottlenecks 

in any project. CFD can be drawn using area charts in MS Excel. 

Below is a re-drawing of a CFD for the same team to check where 

things were at various intervals. 

Story Points 

20 

15 

10 

5 

0 

Figure 2 

Week 0 

Week 1 

Week 2 

Timeline 

Week 3 

Week 4 

New 

Design 

Development 

Testing 

Complete 

The number of items in development increased at the end of 

Week 2, indicating bottlenecks or coding issues resulting in a 

slow movement of items. The team can analyze the graph and 

try to find out what happened at the end of Week 2. Was it poor 

design, or some cyclic dependency on stories, or too many bugs 

to further analyze the WIP? 

There are many other usages of CFDs besides finding bottlenecks. 

CFDs are multi-utility graphs that continuously report the true 

status of an Agile project. CFDs can help in determining lead time, 

cycle time, size of backlog, WIP, and bottlenecks at any point in time.

Story Points 

20 

15 

10 

5 

0 

Figure 3 

Week 0 

Week 1 

Lead Time 

Cycle Time 

Week 2 

Timeline 

Week 3 

WIP 

Week 4 

New 

WIP 

Done 

Lead time is the time from when the feature entered our backlog 

to its completion status. This is of utmost interest to business 

stakeholders. It can help business people decide about the time 

to market for features. They can plan marketing campaigns based 

on lead times. 

Cycle time is the time taken by team from when they started work 

on it to completion status. This helps the project leads make important 

decisions in selecting items for working. 

Created due to popular demand, this two-day 

course caters for a wide audience, giving candidates 

a solid understanding of roles, processes 

and techniques used in Agile projects. It provides 

an overview of the agile activities, building on a 

basic understanding, reinforced through a heavy 

emphasis on discussion and practical application. 

The Agile Essentials qualifi cation is aimed at anyone 

involved in software engineering who wants to become 

familiar with working in an Agile environment. 

That includes developers, business analysts and 

testers. Additionally, senior project personnel such 

as project managers and IT 

directors will benefi t from this 

course, gaining a fundamental 

grounding in Agile techniques. 


WIP is the work currently lying in different stages of the software 

lifecycle. Cycle time is directly proportional to the work in progress 

items. Keeping a limit on WIP is a key to success in any Agile project. 

In Scrum we try to limit the WIP within a sprint, but limiting 

it across the various flow states will help further in gaining better 

control and visibility in a sprint. 

Controlling WIP is the mantra for victory in any project. With CFDs, 

WIP is no longer a black box and anyone can see the work distribution 

at any point in time. Thus CFDs provide better insight and the 

power for better governance in any Agile methodology. ■ 


An exam at the end of the course 

tests for know ledge, understanding 

and application of vital Agile techniques, but does 

not require previous experience in Agile projects. 

For more information and training dates, please 

visit our website: training.diazhilterscheid.com 

Rashmi Wadhawan 

Rashmi is Head of Quality Assurance and Centre of Excellence 

at GrapeCity India and has 12 years of experience 

in the software industry. She is a certified Scrum Master 

practicing the Agile scrum process in her projects. Prior 

to GrapeCity, she worked with Globallogic. She is an active 

member of the process improvement group at GrapeCity 

and is proud to be associated with one award winning product. She has played 

all kinds of roles in the software Industry including business analyst, technical 

lead and test architect. 

Book now! 

Díaz & Hilterscheid 

Unternehmensberatung GmbH 


10707 Berlin 

Germany 

Phone: +49 (0)30 74 76 28-0 

Fax: +49 (0)30 74 76 28-99 


Website: training.diazhilterscheid.com

Security-focused stories: Implementation tips in 

Agile development environments 

by Vishal Asthana & Rohit Sethi 

In the Agile development world, cycles/sprints are very short, 

often no more than two to four weeks. For this reason software 

development teams find it difficult, if not impossible, to comply with 

a long list of security assurance tasks. More often than not, they 

either skip these tasks altogether or choose a subset based on 

their “this-should-be-good-enough-for-this-sprint” perception. The 

need for solving this led to a SAFECode practice paper [1] on the 

subject of which Vishal is the lead author. The paper does so by 

presenting “practical” lists of security-focused stories and security 

tasks for ready consumption by Agile practitioners. 

First through consulting on secure Software Development Life Cycle 

(SDLC), and then more recently through developing and deployment 

SD Elements, Rohit has experienced first-hand many of the challenges 

that Agile development teams in disparate industries have 

with incorporating security into the entire development process. 

For many industries, simply getting developers to pay attention to 

security outside of mandatory testing is a struggle. Compounding 

to that difficulty is the natural bias of agile development teams 

to focus on features that deliver visible customer value, rather 

than implied non-functional attributes such as security. Working 

closely with customers, Rohit has experience with techniques 

and tools that successfully integrate security in time-constrained 

agile environments. 

The authors present implementation tips in this article. 

Implementation tips 

Q) Is a development team’s management buy-in necessary? 

Yes. Buy-in from the management is critical for effective implementation. 

This is especially true in teams where adoption of 

Agile security practices is “optional” as developers typically tend to 

ignore the practices in favor or more pressing development needs. 

Even in cases where developers themselves want to implement 

security stories, they are ultimately accountable to management 

and may not be able to justify spending time away from more 

pressing features or defects. 

Q) What role should an organization’s central security team 

(if it exists) play in order to ensure effective implementation 

of this work? 

The central security team needs to play a mentorship role versus 

that of a security cop. They should help Agile development 

teams systematically imbibe this work and help them overcome 

roadblocks. 

If development teams enjoy a high degree of autonomy, they are 

likely to reject “policing” from the security team. Working closely 


in a mentorship role helps build trust with the development team. 

Still, it’s common for development teams to say they are on-board 

with emphasizing security up-front but subsequently place all 

emphasis on feature development. In these cases, the security 

team will either need to take up a project management role with 

respect to security stories or work closely with a PM/Scrum Master 

to follow-up on security. Simply occasionally reminding development 

teams of their security obligations, and providing visibility 

to management such as the percentage of high priority security 

stories left unimplemented can dramatically improve the uptake 

of security stories. 

Q) Who will select the security stories applicable for my application? 

Vishal: 

It’s more effective to have the team’s architect/security analyst 

select user stories keeping the Product Manager (Owner) in the loop 

at all times. This ensures that the security debt and eventually residual 

risk are estimated correctly at the ‘Definition of Done’ stage. 

As for stories that don’t apply, as long as there’s a ‘why not’ justification, 

it’s ok to not track/include certain stories. If you are 

not able to decide whether or not to include a story, consult with 

your central security team. For example, a pure C#-based product

doesn’t need to worry about inclusion of a story around prevention 

of buffer overflow typically seen in C/C++ applications and can 

therefore safely exclude it. 

Rohit: 

There could be well over 200 potential security requirements (which 

can be translated to user stories) based on common software 

weaknesses that an application may need to adhere to. Providing 

a quick, accurate mechanism to filter these requirements by basic 

criteria is essential for scaling security requirements across many 

development teams. Absent of an efficient and ever-improving 

filtering mechanism, you’ll need an application security architect 

with strong domain knowledge of the application to determine the 

most accurate requirements. This approach only works with sufficient 

in-house application security expertise. Many organizations 

adopt a mixed approach, where dedicated architects focus on the 

highest risk applications and other teams use a self-service mechanism 

with intelligent filtering. Ultimately this comes down to your 

organization’s appetite to spend money on dedicated application 

security employees, which is driven by how important application 

security really is to your organization. In any case, prioritizing these 

requirements based on risk and cost to implement is critical to 

successful deployment in an agile environment. 

Q) How do you drive adoption of the security stories? 

Merging security stories with other non-functional stories helps 

driver user adoption. One of the most common objections from 

developers is expending additional effort just for security when they 

may already have security testing. Merging other Non-Functional 

Requirements (NFRs) with this effort drives adoption. Agile development 

best practices are sparse on discussions of development of 

‘hidden’ requirements from customers, so it’s likely that an effort 

which addresses security, accessibility, other legal/compliance 

issues (e.g. Sarbanes-Oxley controls), availability and other nonfunctional 

requirements will help gain adoption. 

In fact, you may find that developers are more willing to begin a 

dialogue in the first place if your proposed solution incorporates several 

pain points for them rather than just security. Starting an NFR 

initiative that helps developers understand hidden requirements 

can make them feel as though the initiative is actually designed 

to help them rather than add more work from the security team. 

Nonetheless, you should anticipate some upfront resistance to the 

initiative because it ultimately does represent more up-front work 

for developers to deal with. Equipping yourself with hard data will 

help deal with resistance. In particular how many security vulnerabilities 

did you identify prior to this initiative and what was the 

cost of fixing them? For example, how long did it take to build fixes 

for these defects? How could that time have been more effectively 

spent on functional requirements or shipping the release sooner? 

Finally, it’s important to recognize that simply identifying security 

requirements does not mean that the requirements must be met. 

If developers push-back because of the extra work required to 

build out new security functionality, point out that the work was 

always implied, but it was never expressed. If your organization 


doesn’t have the time to spend on implementing the features in 

the short-term, at least you know what risks you are taking and 

you have the opportunity to use other countermeasures such as 

improved monitoring. Identifying the requirements simply means 

that the developers do not have to guess at an implied level of 

security by building, testing for security, and then debating about 

the risk of findings. Rather, developers can work with the business 

and security teams to understand an acceptable level of risk upfront, 

and verification becomes an activity to simply make sure 

that the agreed-upon security level was achieved. 

Q) Who should be the primary actor for security stories? 

Vishal: 

Architects, developers and QA engineers need to be the primary 

actors. 

At first glance, it might appear that implementation would be 

adversely affected in cases where the development teams aren’t 

security-aware. The underlying intent of having the architects/ 

developers play the primary actor role is to have them proactively 

build a security mindset. Here’s how: 

Architects would need to consciously think about the security 

aspects of to their products in order to shortlist security stories. 

As for developers, instead of them completing a security backlog 

task because their Product Manager/Development Manager 

put it in there, (in most cases) they would now need to actively 

learn the method to complete a security task for a given securityfocused 

story. 

In order to accomplish this, they would need training which has 

been made part of the Operational Security Task list that Managers 

need to imbibe in their development environment. 

Who would impart the training? – Resident security experts or 

central security team or external consultants. 

How would that achieve the intent? – Developers would learn the 

way to implement a strong security fix. For example, Difference 

between black list and white list approach and why the latter is 

more secure. 

As for QA engineers being actors in the stories, the intent is to build 

a security mindset within QA teams and to relay to them that they 

are very much a part of ensuring that the product is secure. This 

is because security testing requires them to think about abuse 

cases and use of security testing tools, the knowledge for which 

would need to be acquired by following step (4) above. 

Rohit: 

I recommend putting security architects or security analysts as the 

primary actor in user stories. This, in most cases, is a true reflection 

of the person who most desires the feature. It also makes it clear 

whom to speak to if the user story is ambiguous or the acceptance 

criteria is not clear.

Ultimately, you will likely end up selecting an actor that makes the 

most sense for your organization. If it gets developers thinking 

about and understanding security requirements, then it’s working. 

Q) What if a particular story’s name doesn’t clearly indicate 

the vulnerability it addresses. Is there a quick way to obtain 

that information? 

In such cases, refer to the CWE-ID ((http://cwe.mitre.org) the story 

has been mapped to within the text of the story itself. This will 

help you understand the weakness the story would help address. 

Q) Can’t I leverage any of my existing tools for keeping a 

track of security stories, test procedures etc.? 

Yes, of course. Piggy back off tools you already use, such as bugtracking/Application 

Lifecycle Management (ALM) tools. It’s not 

mandatory to use new tools specifically for security. 

The closer you can get to putting security into the tools developers 

already use on a day-to-day basis, the less likely you are to 

encounter resistance. For example, if your developers use Mingle 

to manage Agile stories, then embedding the security stories directly 

into Mingle will yield better results than having a separate 

word or excel document. You may consider building or purchasing 

a solution to centralize your recurring security stories, such as a 

Secure Application Lifecycle Management application, in order to 

ease integration with existing ALM tools. 

Q) Do we need to select security-focused stories every sprint? 

Adding security stories to every sprint is probably too much overhead 

for most development teams. On the other hand, many 

Agile applications have emergent architectures and their security 

requirements evolve over time. Reviewing the security stories on a 

periodic basis, such as bi-annually, can help capture new security 

stories that may have become in-scope as a result of changes to 

the application. For example, if an application integrates Single 

Sign On (SSO) support as part of a minor release, it will have new 

security requirements that may not have been captured previously. 

Q) Do developers need to work on a set of security stories in 

just the first sprint, or throughout the duration of the project? 

Some stories may have relevance in every sprint (e.g. stories about 

input validation), so reviewing the set of stories in every sprint is 

the most effective usage scenario. 

Q) Do we need to conduct threat modeling in an Agile development 

environment with ever changing design? 

End-to-end conventional threat modeling may not be required. 

Creation of DFDs (Data Flow Diagrams) is still useful though. Once 

these are in place, we recommend doing the following: 

Thorough diligence to select the applicable security-focused stories. 

Application of the selected stories to the DFDs. 


Q) Are the security stories applicable to cloud-based applications? 

Yes. Agile development teams can pick up relevant security stories 

based on the nature of their application (thick client, web-based, 

cloud application, mix etc.). 

In most cases, application code-level security controls for cloudbased 

applications do not differ significantly from other kinds of 

applications. There are a few notable exceptions, such as authorization 

controls for multi-tenancy. Outside the scope of code, however, 

the requirements can vary substantially. For example, legal requirements 

around ownership of data, infrastructure controls, logging 

and monitoring, etc. differ substantially for Software As A Service 

applications and applications deployed on Platform As A Service 

(PAAS) such as force.com. The Cloud Security Alliance maintains 

a comprehensive security controls matrix for cloud deployments 

that maps to many well know compliance initiatives. 

References 

[1] SAFECode guidance for Agile practitioners: 

www.safecode.org/publications/SAFECode_Agile_Dev_Security0712.pdf 

■ 


Vishal Asthana 

Vishal Asthana, CISSP is Sr. Principle Software Engineer 

with Symantec’s Product Security Team. He is the lead 

author for SAFECode’s paper Software Security Guidance 

for Agile practitioners. He has 12+ years of technical and 

techno-management experience across diverse industries 

(Software/Hardware security product companies, reprographics, 

BPO) and holds a Master’s Degree in Electrical Engineering from 

the University of Southern California (USA) and a Bachelor’s Degree in Electronics 

and Telecommunication from the University of Chennai (India). 

Rohit Sethi 

Rohit Sethi, CISSP, CSSLP, is vice president of product 

development at SD Elements. Sethi is a specialist in building 

security controls into the software development life 

cycle (SDLC), and a SANS course developer and instructor 

on Secure J2EE development. Sethi also leads the Open 

Web Application Security Project (OWASP) Design Patterns 

Security Analysis project.

We would like to describe how we start up agile projects, which 

are completed using our ‘Evo’ [6] agile method [2, 3]. 

We have been using exactly this Project start-up method worldwide, 

in many companies, and for both software/IT projects and 

other systems engineering projects (like 25 (now) Boeing Aircraft 

Projects in 1990) for decades, and it works. It gives a flying start 

to the incremental value delivery process; starting with value 

delivery, the 2nd week. 

This process is appropriate for any consequent agile process, 

such as our ‘Evo’, which is focussed on delivering real measurable 

stakeholder value incrementally, as opposed to the majority 

of current agile methods which are focussed on delivering code; 

but, which do not attempt to define or deliver real stakeholder 

value itself, directly. 

One solution to the agile problem of ‘code fixation’, which one of 

our multinational bank clients has recently adopted, for the wide 

variety of agile methods being used in the bank, is to suggest 

that the ‘Evo’ process [2] be added on top of their current agile 

process, for example on Scrum or/and XP. Evo then manages the 

stakeholder value, and Evo provides value design ideas to the 

code development team. 

Evo will not only output ideas for code (a burn down stack), but 

will in fact output any (non code) design ideas that will help deliver 

stakeholder value, such as training programmes, database 

Gilb’s Mythodology Column 

An Agile Project Startup 

Week: ‘Evo Start’ 


by Tom & Kai Gilb 

construction, or motivational tactics. Evo operates at the systems 

engineering level, as Scrum allows in principle. 

The Evo startup week is a sort of feasibility study, in the sense of 

■ Day 1: Drafting a feasible set of top 10 quantified project 

value objectives 

■ Day 2: Drafting a top 10 architecture hypothesis set 

■ Day 3: Estimating the multiple effects of all architecture 

on all value objectives, and critical resource constraints 

(budget, deadline) 

■ Day 4: Suggesting initial value delivery steps, next week 

■ Day 5: Getting management approval to proceed with the 

second week, and to see if we can really deliver value to 

stakeholders. 

The Evo week is intentionally time boxed (one week), no matter 

what the size of the project. This is done so that: 

■ We do not get into weeks and months of bureaucratic 

start up overhead, before we have to deliver real value to 

stakeholders 

■ We will focus on the critical top level objectives [5] 

■ The detailed design will emerge iteratively, as a result of 

value measurement, and feedback. 

Figure 1: Two levels of result management, above a Scrum process. The ‘Business level’, on top of the stakeholder level is missing from this illustration here.

In practice, we gather a small group, a meeting room full, 6 to 14 

people, for a week. Some specialist individuals can come and go 

during the week. When Kai and I do this with a client, we act as 

coaches. This week is also the training course in the Evo method, 

and this practical approach is far better than a week of classroom 

training, It is politically easier to budget than training, since it is 

‘real work on real projects’. 

Day 1: Top 10 Critical Objectives, Quantified 

Real Bank Project: Project Progress Testability 

Quantification of the most-critical project objectives on day 1 

P&L-Consistency&T P&L: Scale: total 

adjustments btw Flash/Predict and Actual 

(T+1) signed off P&L. per day. Past 60 

Goal: 15 

Speed-To-Deliver: Scale: average Calendar 

days needed from New Idea Approved until 

Idea Operational, for given Tasks, on given 

Markets. 

Past [2009, Market = EURex, Task =Bond 

Execution] 2–3 months? 

Goal [Deadline =End 20xz, Market = EURex, 

Task =Bond Execution] 5 days 

Operational-Control: Scale: % of trades 

per day, where the calculated economic 

difference between OUR CO and 

Marketplace/Clients, is less than “1 Yen”(or 

equivalent). 

Past [April 20xx] 10 % change this to 90 % NH 

Goal [Dec. 20xy] 100 % 

Operational-Control.Consistent: Scale: % 

of defined [Trades] failing full STP across 

the transaction cycle. Past [April 20xx, 

Trades=Voice Trades] 95 % 

Past [April 20xx, Trades=eTrades] 93 % 

Goal [April 20xz, Trades=Voice Trades] 

Goal [April 20xz, Trades=eTrades] 98.5 ± 

0.5 % 

Operational-Control.Timely. 

End&OvernightP&L: Scale: number of times, 

per quarter, the P&L information is not 

delivered timely to the defined [Bach-Run]. 

Past [April 20xx, Batch-Run=Overnight] 1 

Goal [Dec. 20xy, Batch-Run=Overnight] 

Past [April 20xx, Batch-Run= T+1] 

1 Goal [Dec. 20xy, Batch-Run=End-Of-Day, 

Delay

Figure 3 is a one-page detailed description of a single top ten 

strategy. We did this by telephone interview with the strategy 

expert (he was snowed out of travelling to work that day), in one 

hour. We used the Design Template in the Design Chapter of the 

Competitive Engineering book. But we did not yet make impact 

estimates, which are in that template. Those will be done day 3, 

and integrated into an Excel Tool (Kai Gilb) with all other specifications 

and estimations. It should be obvious that detailing the 

design, and collecting info on risks, dependencies, issues, and 

assumptions is valuable and necessary for realistic understanding 

of main objective effects, and costs, of the strategy. 

Day 3: Impact Estimation; estimating the value 

for our objectives, and the concurrent costs of the 

strategies 

On the third day, the team attempts a complete estimation of the 

main and side effects, and the costs of all strategies, on all main 

objectives. For a 10×10 table that is 100 estimates, plus maybe 

2×10 = 20 cost estimates. In addition to the estimates, if we have 

time, and want a high quality auditable architecture hypothesis, 

we also add to each estimate: 

■ the ± uncertainty, the range, of our estimate. The spread of 

experience 

■ the evidence, facts, actual measures, measuring processes 

and sources 

Based on the above we designate the Credibility of each estimate 

on a scale of 0.0 (none) to 1.0 (perfect credibility) 

We use the ± uncertainty, and the credibility index to modify our 

basic estimates, in the direction of more conservative estimates. 

We calculate a ‘worst, worst case’. 

Strategies Identify 

Binding 

Compliance 

Requirements 

Goals 

Strategy 

Security 

Administration 

Compliance 

25 % → 90 % 

Security 


Performance 

24 hrs → 4 hrs 

Security 


Availability 

10 hrs → 24 hrs 

Security Administration 

Cost 

100 % → 60 % 

Total Percentage 

Impact 

ISAG Gap 

Evidence 

Analysis 

Oct. 03 

Cost to Implement 

Strategy 

System 

Control 

Strategy 

System 

Implementation 

Strategy 

Find 

Services 

That Meet 

Our Goals 

Strategy 

Use The 

Lowest Cost 

Provider 

Strategy 

100 % 100 % 100 % 50 % 0 % 

75 % 100 % 100 % 100 % 0 % 

0 % 0 % 0 % 100 % 0 % 

50 % 100 % 100 % 100 % 100 % 

225 % 300 % 300 % 350 % 100 % 

15 man days 

(US$ 5,550) 

John Collins John Collins John Collins John Collins 

15 man days 

(US$ 5,550) 

15 man days 

(US$ 5,550) 

15 man days 

(US$ 5,550) 

1man day 

(US$ 1,110) 

Credibility 

Cost Adjusted 

0.9 0.6 0.6 0.75 0.9 

Percentage 

Impact 

202.5 % 180 % 180 % 262.5 % 90 % 

Figure 4. Acer Project: Impact Estimation Table. 


Figure 4, a real Impact estimation table. The ‘100 % → 60 %’ expressions 

on the left are a reference to the Past levels (0 % impact) 

and the Goal levels (100 %) of defined Scale objectives. This is of 

course a different project than the one in examples above. But it 

was less complicated, so we chose it as an illustration. 

Day 3, estimation makes us think deeply about what we have 

proposed, and what we really know about the ideas. It is impressive 

to witness the advanced level of fact-based logical discussion 

amongst participants. 

Day 4: Extract a Value Delivery Step for Next Week 

The 4th day is about finding something practical to do the next 

week (and ultimately each week thereafter, until all Goal levels are 

reached). This applies even when the current system is ultimately 

going to be scrapped. But we will usually install new improvements 

on the current system initially, in order to get some real 

improvements quickly. There is no question of building a whole 

new system, next week, but there is always (believe it or not) 

something practical we can do to start the process of testing the 

architectural hypothesis, to start pleasing stakeholders, to start 

building our credibility and confidence. The Impact estimation table 

has a strong clue as to where to find high value increments. And 

most people (some are ‘in denial’) can think of several practical 

small steps to get us going- 

Day 5: Getting approval to start rolling out the 

value 

The 5th day, sometimes done at end of 4th, or integrated into 

the other 4 days, if the executive participates actively, is simply 

getting a ‘go ahead next week, at least’ signal from a responsible 

manager. This is easy because the lure of real results in the short 

term is convincing. What can you lose? 

Using this process in agile IT projects, such as in Banking, is our 

norm. But the process seems to work in any planning area. In 

1990 we used it on 25 aircraft projects at McDonnell-Douglas. 

We did 5 parallel start-ups, in 5 different weeks, and they all got 

approved. One device we used there, was to involve the executive 

for half an hour every evening. We got daily buy in, correction, and 

understanding by management. No surprises on Friday. 

People learned the agile method, Evo, by doing, rather than any 

classroom training. And we could budget the exercise as part of 

the project, not as a training overhead. 

If you want to try Evo, and Evo startups, be sure to download the 

free standards referenced here [1, 2] as a guide. Let us know how 

this works for you in your agile environment. Or, write a paper for 

Agile Record, or their Conferences.

References 

[1] Evo Startup Standard, Jan 12 2013 

http://www.gilb.com/dl562 

[2] Evo Project Management Standard, Jan 12 2013 


[3] This is a detailed standard for conducting an ‘Evo’ (Evolutionary 

Project Management, Gilb’s Agile Method) as 

described in my book Competitive Engineering, Chapter 10 

[http://www.gilb.com//tiki-download_file.php?fileId=77] 

[4] The slides increments of value delivery (10 min slides) 

[http://www.gilb.com/tiki-download_file.php?fileId=451] 

give a case study view of using this method for DoD. Persinscom, 

US Army IT System. 

[5] “The Top 10 Critical Requirements are the Most Agile Way 

to Run Agile Projects” 

in Agile Record, August 2012, Issue 11, pages 17, 19-21, 


[6] The ‘Evo’ abbreviation was probably first adopted for the 

use of our Evolutionary Project Management methods in 

cooperation with Hewlett Packard’s widespread use of 

Evo, as reported in HP Journal, for example Todd Cotton, 

“Evolutionary Fusion: A Customer- Oriented Incremental 

Life Cycle for Fusion”, HP Journal August 1996. We taught 

the method to Todd about 1988 on an HP Project, and he 

was a champion of the Evo method at HP. http://www.hpl. 

hp.com/hpjournal/96aug/aug96a3.htm 

‘Evo’ is simply a abbreviation of ‘Evolutionary’. Though we 

have played with acronyms like Evolutionary Value Optimization. 

[7] Experience in Multinational Banks, conference lecture 

slides. http://www.gilb.com/dl532. This contains several 

realistic case studies regarding Evo project startup. Testing 

and Finance Conf., London 2012 

[8] Planguage is defined in Gilb, Competitive Engineering, 

2005. ■ 



Tom Gilb and Kai Gilb 

Tom Gilb and Kai Gilb have, together with many professional 

friends and clients, personally developed the Agile 

methods they teach. The methods have been developed 

over five decades of practice all over the world in both 

small companies and projects, as well as in the largest 

companies and projects. Their website www.gilb.com/ 

downloads offers free papers, slides, and cases about Agile and other subjects. 

There are many organisations, and individuals, who use some or all of their 

methods. IBM and HP were two early corporate-wide adopters (1980, 1988). 

Recently (2012) over 15,000 engineers at Intel have voluntarily adopted the 

Planguage requirements specification methods; in addition to practicing to a 

lesser extent Evo, Spec QC and other Gilb methods. Many other multinationals 

are in various phases of adopting and practicing the Gilb methods. Many 

smaller companies also use the methods. 

Tom Gilb 

Tom is the author of nine published books, and hundreds of papers on Agile 

and related subjects. His latest book ‘Competitive Engineering’ (CE) is a detailed 

handbook on the standards for the ‘Evo’ (Evolutionary) Agile Method, 

and also for Agile Spec QC. The CE book also, uniquely in the Agile community, 

defines an Agile Planning Language, called ‘Planguage’ for Quality Value 

Delivery Management. His 1988 book, Principles of Software Engineering 

Management (now in 20th Printing) is the publicly acknowledged source of 

inspiration from leaders in the Agile community (Beck, Highsmith, and many 

more), regarding iterative and incremental development methods. Research 

(Larman, Southampton University) has determined that Tom was the earliest 

published source campaigning for Agile methods (Evo) for IT and Software. 

His first 20-sprint agile (Evo) incremental value delivery project was done in 

1960, in Oslo. Tom has guest lectured at universities all over UK, Europe, 

China, India, USA, Korea – and has been a keynote speaker at dozens of 

technical conferences internationally. 

Kai Gilb 

Kai Gilb has partnered with Tom in developing these ideas, holding courses 

and practicing them with clients since 1992. He coaches managers and 

product owners, writes papers, develops the courses, and is writing his own 

book, ‘Evo – Evolutionary Project Management & Product Development.’ 

Tom & Kai work well as a team; they approach the art of teaching their 

common methods somewhat differently. Consequently the students benefit 

from two different styles.

Masthead 

EDITOR 



10707 Berlin 

Germany 

Phone: +49 (0)30 74 76 28-0 

Fax: +49 (0)30 74 76 28-99 

E-mail: info@diazhilterscheid.de 

Díaz & Hilterscheid is a member of “Verband der 

Zeitschrif tenverleger Berlin-Brandenburg e. V.”. 

EDITORIAL 

José Díaz 

ARTICLES & AUTHORS 

editorial@agilerecord.com 

In all publications Díaz & Hilterscheid Unternehmensberatung 

GmbH makes every effort to respect the copyright of graphics 

and texts used, to make use of its own graphics and texts and to 

utilise public domain graphics and texts. 

All brands and trademarks mentioned, where applicable, registered 

by third-parties are subject without restriction to the provisions 

of ruling labelling legislation and the rights of ownership of the 

registered owners. The mere mention of a trademark in no way 

allows the conclusion to be drawn that it is not protected by the 

rights of third parties. 

Picture Credits 

©iStockphoto.com/SeanShot C1 

©morguefile/jade 6 

Index Of Advertisers 

Agile Essentials 25 

Agile Team Academy 18 

CaseMaker SaaS 9 

©morguefile/seriousfun 20 

©morguefile/mconnors 26 

CAT – Certified Agile Tester 2 

Díaz & Hilterscheid GmbH 2 

Díaz & Hilterscheid GmbH 13 

ISSN 2191-1320 

LAYOUT & DESIGN 

Díaz & Hilterscheid 

Lucas Jahn 

Konstanze Ackermann 

WEBSITE 

www.agilerecord.com 

ADVERTISEMENTS 

sales@agilerecord.com 

PRICE 

online version: free of charge 


The copyright for published material created by Díaz & Hilterscheid 

Unternehmensberatung GmbH remains the author’s property. The 

duplication or use of such graphics or texts in other electronic or 

printed media is not permitted without the express consent of 

Díaz & Hilterscheid Unternehmensberatung GmbH. 

The opinions expressed within the articles and contents herein do 

not necessarily express those of the publisher. Only the authors 

are responsible for the content of their articles. 

No material in this publication may be reproduced in any form 

without permission. Reprints of individual articles available. 

Díaz & Hilterscheid GmbH 23 

SWE Guild 34 

Testing Experience 22

www.sweguild.com 

Page 34 Agile Record – www.agilerecord.com

issue 13

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?