Tag: Agile

Posted on by — Leave a comment

Reflecting on Sprint Length via 1-day Sprints

The foundation of Scrum is empirical process control, a technique to build complex products in complex environments, where few activities are repeatable and the course of work is quite unpredictable. Which is the case for the creative work that software development is.

In empirical process control objectives are fed into a system, and via closed-loop feedback results are regularly inspected against the objectives in order to adapt materials, tasks and process. Skilled inspectors do inspection at an appropriate frequency, so focus and time to create valuable output are balanced against the risk of allowing too much variance in the created output.

Scrum includes 2 cycles and a lightweight set of events and artefacts to do inspection and adaptation upon transparently available information and commonly understood standards.

  • At the Daily Scrum the Development Team inspects its progress, estimates, planning and tasks within the container of the Sprint. All of these elements were initially laid out at the Sprint Planning. They use the Sprint Backlog, the Sprint Goal and a progress trend on remaining effort. It assures they don’t get out of sync with each other and with the Sprint Goal for more than 24 hours.
  • At the Sprint Retrospective the Scrum Team inspects the complete, well, ‘process’. Rather the way they have played the game of Scrum in the performed Sprint. The objective is to define what playing strategies will be applied in the next Sprint. No topics are excluded; tools, technology, communication, relationships, quality, engineering standards, definition of done, … It’s basically about establishing what went well, what shows room for improvement and what experiments might be useful to conduct in order to learn and build a better product.

There seems to be a tendency to move to shorter Sprints. The last version of the Scrum Guide advises Sprints of 1-4 weeks. 4 Weeks being an absolute maximum, I think 1 week is an acceptable minimum.

Let’s say you would do 1-day Sprints. Both Scrum’s described inspection events will occur at the same time, or at least take place at the same frequency. The danger is very substantial that a Scrum Team will focus merely on its daily work and progress, but takes no time to inspect & adapt the overall process and ways to improve quality.

We should also keep in mind that Sprint length is best defined upon the frequency at which the Product Owner and the Development Team need to consult with the stakeholders over a working version of the product and the decision on a functional release of the product. Sprint length will take into account the risk of losing a Business opportunity because Sprints are too long. Well, if your business is indeed so volatile that it is only 1 day, please do 1-day Sprints and release daily. But be careful in burning your inspection mechanisms.

Above all, do organize the Scrum events and enjoy the adaptive power of the 2 mutually re-enforcing inspect & adapt cycles. If you would only release on a weekly base, be realistic and go for the optimal approach, a Sprint that matches your product cycle and takes 1 week within which you will still adapt to reality on a daily base.

Posted on by — Leave a comment

10 years, or so. Piece of a career. Rückblick.

It’s been 10 years since the world was shocked by the brutal airplane attacks on the US. It’s a terrible birthday, but it also reminded me of the fact that it’s been only 10 years of working in IT consultancy for me. But, boy, what a path it has been.

On 9/11 of 2001 I was guiding a junior analyst of a customer of the consultancy company I started working for not too long before. After having heard of some crazy attack, but not even knowing what the twin towers really were, I drove off to an interview with another customer for an analysis assignment. They approved of me, and I started… analyzing. Having no formal background, except a 3-day UML course (hmm, don’t have the attached diploma anymore, I fear), I tried to be pragmatic. Mixing plain text descriptions with Visio drawn screen drafts and flow charts and other diagrams. Whatever seemed most appropriate to get the message across. I later on estimated the project upon a model built by a senior colleague, upon listing screens, field and data types, and expected difficulty. And my management strongly insisted on communicating less days to the developers than estimated. You can’t trust ’em, ya know. But I didn’t, as I didn’t hide the included contingency. Did create a predictive plan. A giant MS Project something matching the expected elapse time.

Having no formal background in project management, I managed to get my team in the same room and do intermediate sessions with the customer. Project room however was organized in a traditional class style (rows) and I was regularly disappointed because my extremely good contacts with customer staff didn’t prevent them from abusing my intermediate sessions for adding scope and changing their mind. Still, we had a fine time, and the project ended (for my employer) in a break-even, which made it even a fantastic fixed price project.

After this project I was asked to start up a new, critical project in very difficult circumstances, i.e. the project hadn’t started yet and was already nearly over time. It only took 2 smart software architects 15 minutes to talk me into eXtreme Programming. Because I saw how XP made explicit, structural and inescapable what I intuitively had tried to do in my traditional project: communication (pair programming, face-to-face) and consistent, clear iterations. Project wen extremely well, ended in time and with profit. Quite extraordinary for a fixed price project. Big-time success!

When scaling up for that same project in a next phase, I was pointed to this thing called Scrum. I read the 2 books by Ken Schwaber available at that time. I went to a CSM course by Ken, where I learned formally not so much, but was excited about the collaboration with Ken and the other participants. We then replaced our organizational practices from XP with Scrum. We kept on applying XP engineering practices though and this felt really natural.

Today I am reading “The Black Swan” (Dutch translation though). On unpredictable, high-impact events. Like 9/11. And I just officially became Professional Scrum trainer from Scrum.org and… Ken Schwaber (Professional Scrum Master and Professional Scrum Product Owner class). You can’t even imagine how proud and happy I am about this. It seems such a long road. Yet, the seeds were sown not more than 10 years ago. And no terrorist or traditional manager is going to ruin my pride.

Posted on by — Leave a comment

Distinguishing Distributed from Dispersed

An upscaling technique for Scrum is installing Multiple Scrum Teams, i.e. fully enabled Scrum Teams that work in parallel. It includes the introduction of a ‘Scrum of Scrums’ to discuss integration aspects across the Teams and the identification of integration tasks for the Teams. The working increment at the Sprint Review should be an integrated result.

It’s all about inspecting reality. A Product Owner cannot figure out whether separate increments work well together without real… inspection. Less than integrated increments leaves unknown, undone work in the system. Putting Quality, time and predictability at risk.

And it would eliminate transparency. Taking away the basis for adaptation, not? Gone are then the pillars of empiricism. No use in putting a cloth over the thermostat if you want the heating to adjust to the real room temperature.

When applying Scrum in a non-collocated mode (or whatever deceptive term is used) the concept of Multiple Scrum Teams is usable if you have complete Scrum Teams at globally spread locations. You will still need some grouping notion over Product Backlog items (themes, packages, features) to orderly distribute work. But every Team has its Sprint Backlog, sprints as a ‘Whole Team Together’ and does a Daily Scrum. The Teams share a ‘Definition of Done’ and engineering standards (as well as source code and integration systems). They figure out a way to do common Sprint Reviews. These are Distributed Teams, full Teams that work together on a Product/platform at different locations in the world.

But people use ‘distributed’ even if they in fact mean Dispersed Teams. When the Team members of a Scrum Team are spread over the globe. It requires a different approach to organizing Scrum, looking for solutions to have a Daily Scrum… daily, with the complete Team (of Developers) at a (convenient) fixed time, and a fixed place. To organize a Sprint Planning with the complete Scrum Team. To have short, direct communication.

Important reasons to think very consciously about the type of ‘distribution’ teams are working in, in order to be well organized.

And, whatever formula is being applied to collaborate across the world, voice calls do not suffice. It requires video conferencing, electronic whiteboards and a virtual form of a shared visual workspace. There is additional overhead. And traveling should be included in the calculations (for collocated Team formation, regular visits, social contacts). It tends to cut the cost cutting that (let’s be honest) offshoring is being used for.

Posted on by — 1 Comment

Different shades of Yes

Training and coaching are important when implementing any new paradigm. Scrum is no exception. But beyond formal assistance, enthusiasm is required, belief, trust, support. After all, it is… change.

Scrum makes enterprises find fun in being competitive again by re-uniting people beyond organizational borders around corporate objectives. But it cannot be forced onto people in an downward way only, nor in an exclusive upward way. Although downstream adoption might seem obvious, it is not always. It can make the real source of improvements unclear. And upstream adoption is surely a lot harder, you can’t do without. Scrum done well, no matter how simple the framework, will transform the way of work so deeply that it will not happen unidirectional only. Because there is more to Agile than meets the eye…

Even confirming a transformation may hold various forms of Yes:

It is very clear that the most desirable attitude is the “Yes, and” form. The minimal form within it is that people mean that they will go for it and will resolve possible impediments. Yes, and we will fix whatever comes in our way. Even better is people saying Yes while thinking ahead, about emerging options and how to already further exploit the adoption. Yes, and we will try x and y as well.

Most commonly people will act from a “Yes, but” attitude. Primary reluctant. Doubting. A tendency to raise objections. Yes, but what about z. This is in general not insurmountable, but it might take time to answer or remove the objections. Wanting to do so requires empowerment, may be time-consuming and is therefore to be observed carefully for real progress. 

Dangerous is the “Yes, but no” response. It represents a political “Yes”, that is at the same time a factual “No”. The promise of a firm decision takes away the conversation. Working results are doubted and blocked again and again. If reviewed at all. Variants include “Yes, but not now“, “Yes, but not all at once“, “Yes, but not too much at the same time“. And new variants will pop up as you try to move forward.

A hideous sub-form is the “Yes, but reality” disguise. Reality can probably not be denied, but is also a very flat generalization. A small dissection will show that ‘Reality’ refers to the existing status quo, where the core idea of change is to challenge that, to build a new reality. This is a very bad case of “Yes, but no” answer.

But, don’t be distracted or discouraged. After all, it is just… change.

Popo Emotions Icons by Rokey.

Posted on by — Leave a comment

More to Agile than meets the eye

Agile is, less acknowledged than but much like Lean, a set of thinking tools and interwoven principles. They are the levers that empower people to faster create better products in a sustainable and respectful way. Typical misconceptions like using Lean for mere cost cutting, limiting Agile to the software department and expecting one, silver bullet, process prevent the emergence of larger benefits.

In Agile, better software products with Built-In Quality are faster achieved by fundamentally re-organizing all activities in an iterative-incremental way and by performing tasks in parallel on a daily basis. A different approach to Managing Risk & Quality.

But let’s have a look at Agile and Lean as blending philosophies, the matching of Agile practices with the main Lean principles.

There are at least 3 major approaches to Eliminate Waste:

  1. Potentially unused inventories (requirements, predictive plans, overdesigns) are not produced upfront. The highest priority work is detailed just in time. A Team will Pull in the amount of work they deem feasible for an iteration, commit to it and build it upon progressive learning and continuous improvement.
  2. Partially done work won’t pile up as an iteration results in working increments. Undone work is prevented by an overall Kaizen thinking, made explicit in a daily Inspect & Adapt stand-up meeting and an iterational Retrospective.
  3. Active Business Involvement excludes unwanted or invaluable requirements. Knowing that only 20% of software functions are regularly used, this represents an enormous waste while showing much disrespect to the people having to spend their time on it.

A Shared Visual Workspace facilitates fast decisions, high interaction and short communication. Openly available Information Radiators are used for the Team to self-inspect and adapt and for external transparency. It shows the real progress upon real efforts and protects the Team in maintaining Sustainable Pace, to assure product quality.

Iterations are timeboxed to Deliver Fast and usable, end-to-end working software that can be put into production. A review with all stakeholders gives the Team outside feedback, remarks and enhancements. Besides this product inspection, an Agile Team will improve its overall operation with a retrospective meeting. Within an iteration however each Team member has the right to immediately Stop the line.

Optimizing The Whole is achieved through active Business involvement and the on-site presence of all technical skills to turn ideas, options and requirements into working software. The Value Stream is optimized because traditional waiting activities like hand-overs and external decisions are eliminated. No macro hand-overs due to a sequential process. No micro hand-overs within the collectively responsible Team.

And, finally, a Manager-teacher, facilitates the Team in teaching the process and removing impediments.

Attached is my complete paper on The blending philosophies of Lean and Agile. It was previously published as 2 blognotes, one for the Lean part and one for the Agile part of the text at the Capgemini Techno Blog.

Posted on by — 2 Comments

Respecting Scrum by doing more

;-) Confession
I did eXtreme Programming before I did Scrum. Although this may seem trivial, it has positively affected my further Agile career.

Let’s go back in time…
In September 2003 my management (consultancy company) assigned me on a project that they hadn’t hoped to win and that was allotted far too late. Result: our company was facing a development effort of 700 days and delivery in December. Two software architects, literally in 15 minutes, convinced me of applying eXtreme Programming. Because I recognized what I had been trying to do in previous projects, but was now sort of ‘hard coded’ in the approach, i.e. iterations and communication.

In only a couple of days we created User Stories, replaced the MS Project phasing by 3 iterations of 3 weeks and convinced the external customer to intermediately attend demo sessions. Our roles included the Team, a project manager/Big Boss (me), a Coach and a proxy Customer. As we soon discovered that our proxy Customer was fully occupied in functional guidance to the Team, we included a Tester to assist her. The Tester incrementally wrote hands-on functional test scenario’s for the User Stories being developed. We added 2 days of slack before the stakeholder demo; to fix small issues, prepare the next User Stories and do spikes.

In 2004 we had to scale and the same fellows (now Coaches) directed me to Scrum. I read the 2 books by Ken Schwaber and registered for his CSM course in May 2004 in Brussels. It was a great experience and as from then we used Scrum for our organizational practices (Sprints, roles, meetings, artefacts) but we kept using eXtreme Programming as implementation for the general Scrum demand of Engineering Standards (PP+TDD, CI+Refactoring). From those engineering standards the use of User Stories emerged, as well as the roles of Coach and Agile Tester.

We always delivered fixed price projects as an external supplier. So we had to translate the customer’s Vision (mostly an RFP) into a Product Backlog, more READY than you would expect in pure Scrum. But we put a maximum length of 1 Sprint on the effort (but usually did it in less time). Our Sprints delivered DONE and potentially shippable work, but we added a final hand-over Sprint (no development!) to close the project. Oh yeah, our ‘slack’ turned into Product Backlog Grooming sessions.

A framework was born.
I went through lots of yo-yo movements over the next years. Even quitting for a while, tired of the slow local adoption (supplier ànd customer side). But… relaunched my ideas as My.Fragility to re-enter the market. And at my current employer we renamed the framework to ScrumPlus, because it does respect Scrum completely, but just extends the base pattern of Scrum to the particular use for delivery of fixed price-negotiable scope projects.

Back to the future
In February 2011, my management decided to apply only Scrum and ScrumPlus in some major Service Lines, abandoning RUP or other traditional approaches.

So I have set up a training program while I will be coaching people in the field. From the training people will get a deep understanding of the base mechanics, principles and emergent Scrum. Project practitioners will get a good understanding of ScrumPlus as instance of Scrum, its base Philosophy of Done, its Agile Project Life Cycle and the 2 Excel tools.

And as you have understood this is largely rooted in my early eXtreme Programming experience.

Posted on by — Leave a comment

Why I loved going to the PSM Course

Early December 2010 I went to a Professional Scrum Master (II) course in Zürich, taught by Ken Schwaber and facilitated by Zühlke Engineering. Already being a PSM II, I went mostly to see Ken and to look to improve my own teaching skills. And it was a very enjoyable event!

Ken and the ScrumAlliance parted in 2009 leading to Ken establishing Scrum.org. As an outsider I don’t care about the circumstances or the rumors surrounding this. I’m only concerned with the profession of Scrum, that I have now been practicing for 7 years and for which I truly believe that Agile is finally crossing the chasm in the lowlands of Belgium and The Netherlands (and other parts of our old continent of Europe).

And I can only conclude that Ken has learned his lessons by:

  • Separating course attendance from assessment/certification;
  • Incorporating community feedback;
  • Creating a development course and for Scrum Teams in general;
  • Setting up a Product Owner program with a separate assessment;
  • Upgrading the PSM course material.

For the latter I can testify that a number of topics were already treated in my CSM by Ken in 2004, but new stuff and ideas have been included far better than in recent CSM course material that I compared it to.

What I strongly like in Ken’s teaching is his holistic perspective on Scrum, like the spirit of the Scrum Guide that he co-wrote with Jeff Sutherland. His courses go well beyond the formal mechanics of Scrum. It’s much more about why Scrum works, its psychology, the positive thinking, the social aspects. And the empirical foundation of Scrum to help us not even trying to predict the unpredictable. And beyond the theory, luckily, Ken has tons of stories and cases to share with the training participants.

This PSM course has certainly inspired me in my teaching of the Scrum Trainings that I launched at Capgemini. At a considerable scale of internal participants and geographical spread. Hoping that I can open these trainings to external audiences, and maybe even as PSM Trainer…

Posted on by — Leave a comment

The iron triangle of valuation

My daily business is software development. I live, breath and practice it from the evil and deviant perspective of Scrum. Scrum is a lightweight framework for complex product delivery. Although the focus is on a product being created, built, maintained, much software development work is organised in projects. There is -semantically- nothing wrong with a ‘project’ in itself. A ‘project’ can be described as a focused endeavour towards an objective. The real problem in the world of IT is the past, and at many places still current, interpretation and definition of a project as a ‘fixed price’ project, a project in which price, scope and time are fixed. A viable return on a project however can only be achieved by balancing 3 elements: time, scope and budget. If there’s no active balancing act (one of the elements is forced or twisted beyond some boundaries) the only element remaining that can vary is… Quality.

Sidenote: if there are no frequent, intermediate releases -see the time constraint- there is also no guarantee on the optimization of value, regardless whether the 3 expectations of end_time+budget+scope are met.

I used to illustrate this ‘fixed price’ mechanism by representing a project as a machine with 4 levers, where the lever for Quality is non-negotiably fixed at ‘High’. As the operator can only move 2 levers at the same time, the last, free, lever will automatically re-position. Trying to fix the last lever will break the machine.

Iron Triangle of Software ProjectsAlthough I still like my machine metaphor, let me hereby revert to the more known iron triangle. And let me start by emphasizing that, although unfortunately often forgotten, there is a 4th element, the inner element, Quality! My triangle with its three project controls on the legs is a music triangle. If one of the legs is deformed, clinging the triangle will lead to an ugly, out of tune, non-qualitative sound. Fixing scope, time and budget will lead to a terrible sound.

Let me use the iron triangle representation in another area to explain where another ugly sound originates from.

In my software business there is a typical and deluding career path, i.e. the virtual ladder that forces people on the path of ‘growing’ from developer to analyst to project manager (and beyond). Scary, enforcing the Peter Principle like that. I fight this unfortunate hierarchical vision by always referring to ‘roles’, and never ‘positions’. And ‘roles’ have everything to do with talent and insights, and not with bossy importance.

Iron Triangle of Work ValuationMy triangle of Valuation illustrates this vision upon the core idea that every person should look for a balance in (1) interests (the love for a ‘role’), (2) the talents to perform well and the ability to do it in an appropriate (3) (working) domain. The outcome of such balanced iron triangle will be proper Valuation, the fact that people feel and are respected. Respect should be interpreted in a broad sense, i.e. financially & in various non-material ways.

Does this model solve everything? Of course not. One’s talents might be big in a domain that the person doesn’t care about. Or a person may believe in having a certain talent, that aligns with his/her interests and make it a working domain. And still not be valued. Might be that your talent isn’t what you hoped it is. Might take time to get valued. Might never come. If you’re happy and having FUN, you might not care and keep believing.

An Agile approach to Human Resources policies does not only respect people (as individuals and as Teams) and promote sustainable pace (to name a few). But well performing in ‘Roles’ will be valued more than striving for positions, and the iron triangle of (work) Valuation is a better reference model to have a good (frequent) dialogue over the balance in it, job satisfaction, performance and… Valuation.

Posted on by — Leave a comment

The roots of Business as Unusual

Before joining Capgemini Belgium in March 2010, the VP of Technology Services gave me a book that was co-authored by Andy Mulholland, CTO of Capgemini global.
Mashup Corporations (The End of Business as Usual) turned out to be a curious book. It has a story line, but it’s not a novel. It’s not a highly literate, fictional or romantic piece of work, but a very direct and effective tale about… technology. About uplifting technology to Service-Oriented Business Transformation.

The authors describe the transformation process of a fictitious company. Vorpal inc. is an important, but very traditionally organized, player in the market of popcorn popper machines. It enters new markets through the use of its ‘shadow IT’, leading to a top-down transformation to fully service-oriented operation, in order to cope with the continual changes and new demands of the new channels. It thereby builds new internal structures and more integrated (win-win) external relationships.

Vorpal makes the shift from ‘hub IT’ to ‘Edge IT’ on the wagon wheel:
(1) The ‘hub’ holds core enterprise data, clear and predictable processes and monstrous applications to maintain it;
(2) To reach new businesses, Enterprise applications are customized and refined;
(3) The ultimate level of flexibility and dynamism is achieved by opening up to new worlds via controlled services.

Agile is only briefly mentioned in the book, but in my Scrum Evangelist opinion, Agile development methods are the perfect match for this transformation. Deliver quickly, with high quality but on a less formal base. Go to market, learn and adapt.

This book should be on the reading list of every CTO or CIO !!!

Note: You can download my full paper on the book and the link to Agile.

I also published the complete story on the Capgemini Technology Blog, for our Business As Unusual program:

Posted on by — 2 Comments

Managing Risk & Quality with Scrum

It’s a strange, yet wonderful, world, our world of Software Development. Where success is often considered a coincidence, a lucky shot and too anecdotal to believe. Although I have a proven track record of successful projects with Scrum (figures and data included) I still try to present various angles to my results. Here’s my perspective on Risk & Quality…

Risk

In a traditional project, a number of phases and activities are typically performed separately and sequentially, upon the belief that extensive descriptions, signatures, sign-offs and hand-overs assure a good result. However, as practice shows, users and customers don’t realize what they’ve asked, described and signed until they get their hands on it. In the absence of that, risk just piles up. And when the usable application finally becomes available, all additional work, rework, tasks or activities will immediately force the project out of time and out of budget.

In our Scrum projects we slice the work in timeboxed iterations (Sprints). We re-organize the typical IT activities drastically because we perform them daily, in parallel and in every Sprint. We build and demonstrate working software at the end of each Sprint. Feedback and change is processed in the next Sprint, keeping us at all time in line with (changing) expectations. But, it’s true, we do not spend countless effort and time on upfront work. Risk therefore seems high at the start, but upon delivered results it will quickly decrease and keep steadily decreasing:

Quality

The ultimate evidence of quality is in working software. As we deliver that frequently, functional quality can be easily determined (and quickly improved). Business Value therefore continuously accumulates where in a traditional approach it is more delivered as a big (disruptive) burst.
The underlying technical quality of the software is assured by the daily, integrated testing and the application of good ‘engineering standards’. We implement these standards with our (daily performed) “Quality Loops”:

Here’s a movie

When creating a presentation on the above, I started a little experiment with the recording option of PowerPoint (version 2010) and succeeded in creating a movie of my presentation. And however improvised and somewhat rudimentary it may be, I’m just gonna leave it like that…