Principles and anti-principles

Who heard of agile software development very likely heard of the Agile values and principles. These are quoted in the agile manifesto that you can read here.

I think that the fact that agile methodologies are backed by that conceptual framework is extremely effective and powerful (in addition to be a genial marketing move): it gives you a common background or system of values to think about when you are facing a problem and you are trying to figure out a solution. I believe the power of agile principles and values is the charge of positivity in finding good solutions that will make you a step forward in the right direction.

What I am realizing and experiencing lastly is that agile principles and values have also a negative charge, the dark side of agile principles… 🙂 Let me explain. I consider a positive charge when in front of a problem we think at the values and they show me the right path. For example, in front of a customer that changes his mind about a feature, instead of pointing out that in the statement of work we said the features would have been different, we work with the customer to see how we can fit the change in the plan done together.

An example of negative effect of the principles and value is when they are used like a shield, or worst a ax, to make sure that something we do not like does not happen. I do not like to write documents? then I bring the principle “working software over comprehensive documentation”; I do not like this or that tool? then “individuals and interactions over processing and tools”; somebody asks me about my missed commitments? then I bring “responding to change over following a plan”. In other words, instead of trying to understand the underlying problem and finding an agile solution, I sometimes see the tendency to hide our-self behind the excuse that things should be done differently. “You want to be agile??? then you must follow the manifesto!”. How to do it is considered irrelevant, there is always another better way to do anything. What the underlying issue or problem that we want to solve is not important. The only thing that matters is that if you want to be agile you MUST follow the rules…

To me this is very anti-agile and turns the principles in anti-principles and the values into dis-values.

I think that part of the problem is that the agile manifest is often read superficially. In the above I used principles and values almost interchangeably, like they were almost the same thing. I’ve done it on purpose because it is what I hear very often. But reading carefully the agile manifesto, there is an important distinction between the two. The manifesto says

...Through this work we have come to value:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

And after that:

That is, while there is value in the items on the right,
we value the items on the left more.

The first thing I would note is that those are the Values. They are not the principles.

Secondly, what the manifesto says is that even recognizing the value of the right side of the sentences, the left part is more important.

The two observations above are important IMHO, because on one side, the agile value system shows you where you should look at when in doubt, on the other side they implicitly express that there is a balance you have to consider between the agile value system and other value systems (customer’s organization, your organization, business constraints and so on).

Where the principles come from then? ehehe, I do not know for which reason, but they are after the list of the Agile manifesto promoters and the copyright information, that is below where you usually would stop reading a web page. If instead you scroll a little, you will see the “Twelve principles of Agile Software” link. This is a very interesting reading, actually I would say the most challenging part of agile development. Those are the Principles and they are quite demanding. They start from putting at the highest priority early and continuous delivery of valuable software, to the delivery of working software frequently, to getting together business people and developers and so on.

The difference between values and principles is that the latter are a kind of normative guidelines derived from the values. I said guidelines because who is serious about software development knows that each team is different, each person is different, each organization is different. Therefore the challenge is always how to apply the agile values in a specific environment, putting in practice at the best in the given circumstances the principles. What’s funny is that I am sure that waving the agile values you could sustain that any of the principle should be avoided. For this reason it is not only important to have the values in mind, but also the principles. When we see a practice that seems in contrast with the values we should also ask why it is in place, and if it aims to achieve any of the principle. If so, we can pic of the two choices: propose how to improve things, or waiving the values and shield our-self behind them…

Release planning is done

Release planning is done. I must say they were two very intensive weeks. The teams really felt load. It was something very different from what they are used to do and therefore took some time to get used to. And probably no one got accostumed to it :). But the result was great. Soon we realized that not everything we wanted to do could be done in the timeframe we set and therefore we looked for alternative routes and ways to do things incrementally. The USs we developed were in most cases good USs (as opposed to tasks masked by stories) and the ammount of USs defined and evaluated is remarkable.

We estimated almost 400 user stories and then selected about 200 for the next release. I really look forward to seeing how the iterations go.

Shouldn’t engineers just be engineers?

During release planning we do two things: estimate user stories and write and refine user stories…

One of the question I asked myself when I knew for the first time about USs and how an agile team works with the product owner to get and refine user stories was… developers are developers, they are trained and paid to find and implement solutions. Why should we ask them to be a bit of business analyst too and define the user stories?

The other day, one of my best engineer came with the same doubt. Do not get me wrong, it was not a critique or a way to quit what we were doing, but a perfectly legal doubt in the back of his mind.

The answer I gave myself at first was that not necessarily developers will have to write user stories. In a perfect scrum world, the product owner(s) has(have) the bandwidth to fully write and refine the user stories. Engineers should just focus on making sure they discuss the stories with the product owner(s) so that they understand them fully and then estimate and implement the stories. In many real cases, where the customer is not an internal product manager, this can be much more difficult, because as anyone, the customer will have many other priorities than writing stories. But in this case, an agile team can just incorporate a business analyst that proxies the customer and acts as the product owner toward the development team.

There are however some good reasons (i.e. reasons I consider good) to have engineers more involved in writing the stories. First, if the project is of any not trivial size, the number of user stories grows easily big, so big that you would need to add many business analysts or product owners (in addition to big walls on to which stick the cards 🙂 ). In such case, you probably go back to involve the development team in helping out. The other reason, which is the most important, is that writing the user stories engineers are forced to see things with the eyes of the users, more than with the eyes of a technician. To make fun of ourselfs we coined the following acronym: MFMU… Maximu Flexibility Minimum Usability. It was because as engineers, we tend to thinks about how a feature should be done and how the code can be changed easily. This usually despite the usability of the final solution (users will do what we tell them to do…). This is particularly unpleasant in software product development, because when you develop a software product, you can achieve the best result when developers think like users. This fits well with the agile principle of releasing workable software. Most users can live with few features but working, much less with the promise that they will have one day a perfect feature set (which we know already will take a couple of releases to get stable 🙂 ).

Writing user stories helps engineers to switch for a moment from the how to the what and this brings the benefit of understanding much better the requirements, the why things should be done in a certain way, what is really important for the user and what less, what the user will do to accept a story and so on.

This is why I am more than happy we need to help our POs in writing and refining the USs. We are not super good yet, but we will get there!

Some additional comments. Interestingly, another engineer came few days after the first with almost the same argument. Easily the discussion slipped to asking ourself if the focus of a software engineer should not be more on producing quality code than writing user stories. Or, in a way, if we should not focus on making sure we can change our code easily before trying to develop with an iterative (possibly incrementally) development process.

First of all let me say that of course it is fundamental that developers write quality code. This is a good part of a developer professionality and it must be  a field of constant improvement. Still, I like my developers put their hands in the user stories because I believe it is equally important they streer their ability to write code toward the final and ultimate goal of software development, which is delivering value for the users. As a manager I am in the middle between the development team and the product team and in many cases I feel the two teams think about value of software development in two very different ways. Developers tend to see value in writing good quality code, the product owner tends to see the value in features delivered to the user. Scrum gives the great opportunity to get these two views closer and see a common goal: deliver value to the user in the most efficient way. As this sentence shows, there is a sequence that makes sense: first deliver value to the user, then constantly improve your efficiency.

Iteration length

Finding the right iteration length is quite an interesting challenge. Or most probably it is a challenge when you you are a beginner in iterative and evolutive software development processes. It is true that the literature mentions that an iteration should last between one and four weeks, but still one or four weeks is a bit different :). Plus, different agile teams use different lengths and some go veerryyyy extreeeeemmmm! I know of teams with iterations of 2.5 days (yes! 2 days and an half!). Quite amazing, isn’t it?

Recently we decide to shorten the length of our iterations. We originally started with 4 week and at the beginning it looked a good compromise between keeping a constant and predictable pace and the overhead that the iterations seemed to add (iteration planning, design presentation, product presentations and retrospective meeting).

I must say that from the point of view of establishing an heart beat for all teams, it worked pretty well… but after three iterations we realized the iteration was too long. The first signal that shown us that something was wrong was highlighted by the iteration burn-down chart of the completed user stories. Take a look at the following chart, which is the average of the three scrum teams:

The Y axis is the number of story points to be completed and the X axis are the days of the iteration. There are a number of things I do not like of this graph: first, the accomplished story points is about 65% of the commitment. This is one of the biggest challenges we are facing: we are not predictable enough yet. Note that the result above is not due to big surprises we encountered during the iteration. What’s particularly interesting is that the line did not go down for half of the iteration, then it started to decrease. This behavior is more evident in the burn down below which regards of one of the teams (but the same pattern was similar for all teams):

Let’s ignore for now the peak, again, no stories were declared done until mid iteration, than finally things started to get better and at the end the team almost hit the target. In general, I believe this trend is due to two main factors:

1. teams tend to commit optimistically
2. our definition of done strongly depends on QA people acceptance, and nothing can be accepted until at least has been developed and is ready to test 😉

Both issues share a common root cause: we are not good enough yet in breaking down user stories in something that can be developed and tested quickly so that work can be declared done earlier. What can we do to fix this situation? We will indeed keep learning how to split user stories before we start the iteration, but one thing we thought is that  four weeks is still a quite long period of time for people to realize that a story is not of the right size and cannot be completed in one iteration. What we noticed is that teams are often optimistic about commitments and like to try to commit more work more than less work. I must admit I like it, it would be a much bigger problem dealing with teams afraid of committing work. But I think predictability and reliability is important too, therefore I would like we try to achieve better trends in our burn down charts.

After thinking about it, we thought that reducing the length of the iteration to two weeks should help the teams in being more realistic in their commitments (they have now to plan for two weeks only!) and in seeing more clearly when a user story must be broken in smaller pieces.

Another signal that suggested us to shorten the iteration length was when we had a couple of customer related issues that required some attention by the teams. One of the principle of scrum is that teams must be protected as much as possible from external impediments and interruptions. Therefore we need to tell customers to wait the next iteration in as many cases as possible (indeed, critical issues are a different thing). Telling customers they have to wait one max two weeks is much more well accepted than 1 month 😉

Another need that would benefit from a shorter iteration is product related. We deliver monthly product updates called “phone packs” that contain for example support for new phone models or carriers or small updates to the database and so on. Customers are starting to ask us to deliver more quickly such packages, potentially as soon as a new phone hit the market. The result of a shorter iteration is here pretty evident. It would allow us to schedule a new phone pack feature twice a month instead of once.

Well… It is enough to at least give it a try, isn’t it? 🙂

From the next release we will use two week iterations for all teams. Let’s see what happens 😉 Stay tuned, I will keep you updated.

The decline of agile or need of a pragmatic approach to agile?

Recently, a number of interesting posts has shaken the tranquil days of the agile movement. Two remarkable ones are:

• http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html
• http://blog.tmorris.net/agile-is-falling-like-religions-do

Of the two the most interesting is the first one by James Shore co-author of “The art of agile development” and agile trainer and consultant.

I would summarize the post with this paragraph:

“Now many people who call me already have Agile in place (they say), but they’re struggling. They’re having trouble meeting their iteration commitments, they’re experiencing a lot of technical debt, and testing takes too long. So they hire me to help them with one of these things. When I go visit, I see a team that is nominally agile, but is suffering huge numbers of problems and is anything but the joyful, settled, smooth-running workplace I expect from an agile organization.”

I think the most interesting information in the article is that he is experiencing that many teams in the real world are failing in applying agile principles and practices. I find it interesting because I believe it is related with the essence of this blog. The author presents his frustration in seeing teams defining themself “agile” and then failing in applying the most basic practices. I must say I am not surprised. I am not surprised because I know what turning a team from a more traditional software development model to a more evolutive and incremental development model means.

But this is not the most important point, for what my opinion counts. I believe that what is happening is not the decline of agile, but that it is entering his maturity. More and more organizations are adopting or are willing to adopt agile practices and therefore those practices are now challenged by the variety of real world environments. Many thinks and tell you that once you learn the agile manifest you can go back to your office and change everything in a blink. In too many occasions I heard people telling me that in order for agile practices to work, you first need A+B+C… in other words, it is too easy to assume that you can start always from the optimal conditions (you have the best and skilled team, very agile-motivated, all co-located, all willing to develop in pair, etc, etc)… what does it happen then if some of these conditions are not met? Shouldn’t agile techniques be pragmatic by definition and therefore allowing to face changes? I believe they should! Why then this is not happening?

My explanation is that there is the tendency to make of the agile methodology an ideal model, that guarantees brilliant results, once all the preconditions are met. But it is very difficult to find such preconditions all met in real world teams. The risk I see is that we replace an ideal model, the waterfall, with another ideal model, the agile. The waterfall is not applicable as it is in real environments because in the majority of the cases you cannot snapshot at time 0 the requirements, the design, the code, and so on and then hope that nothing changes. What happens if we build a methodology that requires so many things to happen at the same time all depending by each other and then one or some of the prerequisites are not met. All the methodology falls apart exactly like waterfall.

This is why it is fundamental that agile keeps its pragmatic nature. And I believe agile does so if accepts to face the issues of real world teams, without necessarily asking them to change everything and in once. I believe agile does so if accepts to face the business aspects that real world teams face every day (a co-located team can be simply not an option from a business perspective!). I believe agile does so if accepts the challenge to scale in size and in time. But most of all, I believe agile does so if instead of being considered a goal to achieve, it becomes a tool to improve quality and efficiency.

There is a risk, though, that we should avoid as much as possible. Pragmatism can sometimes hide the forces that resist to changes. Be pragmatic must be a way to improve things in a controlled way, taking calculated risks and being honest with yourself about your team. It cannot be the escuse to always find a reason why things should not change.

Seminar on Agile Software Development at the University of Pavia

In the past couple of weeks I and Edo presented a seminar on Agile Software Development at the University of Pavia.

The seminar was divided in four lessons of two hours each and was very kindly hosted by Prof. Antonio Barili in the Software Engineering course.

Goal of the seminar was to get the students familiar with the agile approach to software development and the associated terminology and practice.
And in fact, even withing a so short time, we wanted the student to “touch” with their hands some of the agile concepts, in particular the iterative approach as a way to improve estimates and plans and planning in story point as the basis of making estimates in size more than in time.

I have to say I am very happy about how the lessons went. There were about 12 students from the university plus 5 of our new hires. The students demonstrated to be very interested and attracted by the topics and how they were presented and participated with enthusiasm to the practical activities.

The program of the seminar was the following:

November 6th

• Software development models (pdf)
• SCRUM part I (pdf)

November 7th

• SCRUM part II (pdf)
• SCRUM ball game (pdf)

November 13rd

• Agile estimating and planning (pdf)
• Test driven development (pdf)

November 14th

• XP game

If by chance you attended the seminar please leave a comment about how much you did like/dislike it and possibile what you would do to improve it.

Why SCRUM?

I guess this is the mother of all questions… And I actually thought there was no need anymore to answer this question in the team. I instead realized at the latest release retrospection meeting that some people in the team could not answer theirself this question… It was a very good feedback that told me I did not communicate it properly and/or I did not make sure everybody understood what we were doing and why. This post is a first attempt to explain the fundamental reasons why we adopted SCRUM (but I’ll make sure to have other in-person occasions).

First of all I must say adopting SCRUM was not something that the developers (in a broad sense, I include anyone contributing to the development of the product) asked to do. One day I woke up and decided we need such a change. I take all the responsibility, good and bad of this decision.

Here is what I think about software development. The development of a software is made of separate and discrete units (the developers) each working on a piece of the product or project and therefore in some way interacting each other. Potentially each unit may be driven by different forces, be influenced by many internal or external factors, tend to move quickly towards a goal or be static, vibrate consuming a lot of energy and going no where or try to figure out how to maximize the result with the minimum effort. Potentially (still) software development is an anarchic process, or, if you want, an art (this is the way usually people like to represent software development in order not to have any constraint and restriction 🙂 ).

I think of the software development process as the way to organize and discipline the interactions between developers in order to achieve a common goal.

If you lack a process, you risk that each developer goes on his/her own, developing what s/he thinks is what the goal is in a disorganized way. If developers were molecules, you could see this absence of a process like a gas (as a state of the material). In an environment ruled with very weak rules, people may work even very hard but due to the lack of directions, in a inconsistent way, resulting for sure in not hitting any remarkable goal.

At a complete opposite side, a team of developers can be very well structured and organized. You divide the team in functional teams, define tech leads, managers, junior and senior developers and then define rules: a process to define the requirements, a process to estimate them, a process to define a plan, a process to manage the plan, a process to manage changes to the plan. With a strongly structured team the tendency is that all those processes depend on some key responsibility, person, role. The analyst must define all requirements, the architect must validate any small change, the tech lead must estimate and decide the tasks to do, the project manager must check where each single resource spends his/her time and fine-grain follow the whole process. Due to the many centers of responsibilities those processes tend to become very formal and rigid. The main advantage of this approach is that it really keeps the established order and in a way it makes very simple to determine who is in charge of what. On the disadvantages side, it is pretty clear that such organization is very difficult to scale because it requires to scale the whole organization, increasing the number of middle layers. Again, if engineers were molecules, you can see this rigid ruled model of interactions like the team was a solid (as opposed to be a gas). It has its own shape and volume that you can see easily, but what happens if something changes or has to change? It is more likely that the solid breaks than changes its shape. Another disadvantage I noticed in a “solid” organization is that people in the team can take two main approaches with regards to their lead or manager: try to take their place or let them lead completely. Both attitudes are very bad; the former because generates a lot of frictions and makes people not work together, the latter because makes the environment even more rigid since people tend to wait that somebody tells them what to do next (see JTMWTD).

What does all the above has to do with Funambol? Well, I introduced the team here. Let’s introduce the product now:

• Funambol is a product company
  • i.e. No consulting
• Push email product
  • Blackberry open source
• Client and server components
• Carrier grade server
• Many components
  • Synchronization service
  • Push service
  • Inbox listener service
  • PIM listener service
  • a portal
• Multi platform clients
  • WM (smartphone & pocket PC)
  • Win32/fat clients
  • Symbian
  • J2ME
  • BlackBerry
  • iPhone
  • Android
  • Mobile linux
• An online portal (my.funambol.com)

as you can see a quite complex product with many components. The most obvious approach in terms of team organization was by functions with leaders that concentrate the responsibilities of the development and the deliveries. I must say it was working pretty well. I had three or four specific persons to who I could go to ask for feasibility, efforts, deadlines and so on.

However, the product was still expanding and being everybody very busy, I started to notice something concerning. Fundamentally, the leads had to work more, trying to balance their role of being the leaders of the teams, but also the experts of the components they were in charge of. I started to notice that things were not moving forward alone, and many times the intervention of the lead was necessary to have a good delivery. I think the leads have been doing a terrific job and they were able in many occasions to resolve very critical situations. But then I started to ask myself if this model would have scaled with the increasing number of components. I was also concerned because I was noticing that people in the teams were not growing at the speed I wanted. I started to ask myself “why am I hiring senior people if I don’t let them fly?”. I started to get too concerned that people would have turned into YTMWTD people… I instead want that engineers are free to run on their legs, and fly, limited only by their creativity (and my business constraints 🙂 ). The “solid” model does not scale, does not free people creativity, does not let people become real owners of the product they are contributing to. We needed to change!

I haven’t been ever attracted by XP and I maybe I’ll never buy it (but never say “never” 🙂 ). What instead I believe is the real fundamental switch that will help us in changing the situation above is SCRUM. SCRUM sells itself very well, because it has something to give to managers. The iterative approach and the possibility to change priorities between iterations is a succulent sweet for product managers and the top management. However, I do not think it is the key. You can have an iterative process with a mini waterfall cycle, and believe me, it would work very well.

The key of SCRUM is that it forces people to take care of things, to feel the ownership of user stories and tasks, to be proactive and creative about what they are developing. In some way, it breaks the intrinsic hierarchical relationship inside the teams and allows the good developers to emerge. This is exaclty what I wanted and needed. SCRUM frameworks engineers work into a firm, but adaptable set of rules that turns software development into a “fluid”. A liquids has its own volume, but it takes the shape you want it to take. Therefore you can shape your software iteration after iteration, but people contrubute to the final result at their maximum. Each member of the team is invested of the responsibility to estimate stories, commit them, develop and test the software s/he developed. All this requires that each person feels a sense of ownership in all they do that the “solid” approach makes much more difficult. This is why I like SCRUM, this is why I wanted to introduce it into my team.

Release Retrospective Meeting… at the park

Yesterday was the day of our Release Retrospective Meeting, but this time we did it in a nicer place than the meeting room.

Thanks to the season we decided to do it at the park 🙂

If you’re going to plan your next retrospective meeting, I’d suggest you to think to do the same: being in a different place, no walls, the sun, the green…. it helps you a lot to survive to all those answers to the “What went wrong?” question. They appear much better and you start to be inspired for the related action items… in other words you feel the pain of what went wrong but you are more optimistic and find some more action items.

Following some photos…

Quality is a state of mind

The past couple of weeks I was on vacation… ok, not at a nice and sunny beach, nor at relaxing mountain resort. I was at home to supervise some remodeling work I had to do in my house. This does not have anything to do with software indeed, but it was a great experience and I took advantage of having my mind out of development to watch closely how the construction workers worked. What does this has to do with quality? Well, being my house, and being just a remodeling I was paying very much attention to the fact they had to do the work in the best way, in a constrained environment (the house where I live) and respecting the deadlines. In short, they had to do a high quality work. And from what I’ve seen, they have done it! They have done the remodeling without breaking anything else, a little ahead the best-expected deadline and making some additional work. It was great, wasn’t it?

I compared construction work to software development and tried to extrapolate common factors that could be applied to so different fields. The general comment I have is that once more I realized that quality is, before anything else, a state of mind.

Below are some of the things that I observed and some lessons I learned.

1. Before selecting the building company I looked for feedback. Everyone I talked to had great feedbacks about a small team of carpenters, the Bisi brothers. They are two brothers plus one coworker and they always work together. There is no way you get just one of them or you ask them to hire someone else. Watching at the results, I learned two lessons: first of all, reputation matters, and if you are good, people will acknowledge it; therefore, listen to feedback (and do not watch only the economics). Secondly, they are a team, a very committed one, passionate of their job: basically a scrum team!
2. Bisi brothers do only the construction work; I also needed an electrician, a plumber, a painter, a parquet poser (sorry if the translation is not accurate, feel free to suggest a better one) and so on. I asked Massimo (the oldest brother, a sort of team leader) if he knew anyone that could recommend; indeed he has his network of specialists. All the people he brought and I met were very good technicians. Plus, Massimo’s team was very clear in telling me if anyone I mentioned to them and they knew were not going to do a good job. Lesson learned: real quality people brings quality people.
3. In the case you do not know, the vast majority of Italian houses are built of bricks and hollow bricks. You cannot imagine, unless you experienced it, how much powder is generated when they collapse a wall! WOW, it is a nightmare! I know already I am going to broom it away for a couple of years. You would therefore assume that in doing remodeling the workers are going to work in the mess until the end of the work and then clean the ruins all together. Or even worse, leave the whole cleaning to you… Not in Bisi brothers case. Every time they finished a section or area of work, they cleaned everything away. Lessons learned:
   1. Quality is not only about the final result; it is a state of mind. Note that in the case of construction workers there is a very concerning factor which is workers safety. Bisi’s team has never experienced big incidents or injuries. I understand now why. You need to take care of each step in your process in order to minimize the risk of incidents. Turned into sw development, you have to look for quality in anything you do, from the scketch on your paper notepad to coding, commenting, unit testing and so on if you want high quality.
   2. Bisi’s team was applying many agile principles. Instead of completing the whole collapsing work and then cleaning up, they proceeded almost by user stories and then by tasks. A task was not completed until, for example, the ruines were not removed.
   3. You need to be careful in anything you do and ask yourself questions, if you want to achieve quality. One thing I really appreciated of Bisi’s team was that many times they found out issues and noticed things that could be wrong or required directions. Many times small things, but anyway things that I would have noticed only when it was too late.
4. It is important you are able to say NO so to set the proper expectations. I notice even in my team that people sometimes tend to not to say no, just because they think I want to hear that we can do something. Bisi’s team was not afraid to say that something could not be done as I wanted/expected. For different reasons, maybe even just because the result would not have been of the quality standard they are used to. I appreciated it, because this allowed me to reset my expectations and to change my plan accordingly. The lesson I learned is that if you know your domain, do not be afraid to say NO, even if this is not what people expect.
5. I sow for the first time many tools. From different kind of mason’s trowels to different types of hummers, drill-drivers and circular saws… tools are important and it is important to use the right tool for the task you have to do. Lesson learned: quality teams have the best tools and know when to use them. Note that not necessarily the most advanced tool is the most appropriate or usable. I was amazed by the use of the mason’s trowel. It is such an ancient tool but with a usability that is difficult to find in anything else/
6. It was very interesting to note that Bisi’s team worked very similar to a SCRUM team. They haven’t been doing formal SCRUM daily meetings, but I am sure they communicated each other when they first met in the morning some guidelines for the work to do in the day. Indeed, in the case of construction work it is easier to see what has been done and what is missing. Anyway, all three had very clear in mind the final result and they have been picking up  a task to do autonomously, without the need of one telling the others what to do. They were constantly communicating and the results were under everyone else’s eyes. I was there when they needed to make some decision for which my input was necessary. They have been extremely efficient and productive, and that’s way the results were so good. I could not tell them, but I helped them simply removing the obstacles they encountered during their work and creating, for what I could, a good environment for them to work. The cost for me was a good number of chocolate bars, but I am sure they will remember it when they will present the bill! 😀 (or at least I hope so).