|
|
Mondora s.p.a. propone ai propri clienti l’Extreme Programming (XP), un approccio ponderato e disciplinato allo sviluppo del software che pone al centro la soddisfazione del cliente.
La metodologia permette di rilasciare il software che soddisfa le necessità del cliente quando queste si verificano.
XP, infatti, permette ai programmatori di mondora di rispondere prontamente alle richieste di cambiamenti nel software, anche in uno stato avanzato dello sviluppo.
Questa metodologia richiede il lavoro di gruppo: i Manager, il cliente e gli sviluppatori sono parte del team che si dedica al rilascio di software di qualità.
L’aumento di produttività è dovuto ai quattro elementi essenziali dei programmtori XP: comunicazione, semplicità, ritorno di informazioni (feedback) e coraggio.
Il coraggio richiesto ai programmatori è quello di avere un approccio più attivo nella loro attività: devono “mettersi in gioco” quotidianamente, crearsi stimoli e affrontare continuamente delle piccole sfide.
Comunicano con il cliente e con i programmatori personalmente, mantengono il disegno del software semplice e ordinato, ottengono feedback testando continuamente il software, sin dal primo giorno. Rilasciano il sistema in tempi brevissimi e implementano i cambiamenti sulla base delle esigenze del cliente.
Mondora s.p.a. ha una vasta esperienza nell’utilizzo di Scrum, una metodologia che implementa un approccio empirico basato sulla teoria del controllo dei processi. L’approccio empirico reintroduce flessibilità, adattabilità e produttività in un sistema di sviluppo.
Il termine scrum descrive un tipo di sviluppo originato inizialmente in Giappone. All’inizio, nel 1987, è stato utilizzato da Ikujiro Nonaka e da Hirotaka Takeuchi per descrivere e lavorare in ambienti iperproduttivi.
Scrum, nel gioco del rugby, rappresenta la mischia in cui attraverso la collaborazione di diverse parti (la prima linea, la seconda, la terza e il mediano di mischia) si rimette in gioco la palla. Esiste una certa similarità tra il gioco del rugby e lo sviluppo del software: sono entrambi adattivi, veloci e auto organizzati.
Oggi accade spesso che i progetti di costruzione di sistemi software falliscano a causa della sottostima del progetto e della mancata definizione dei requisiti. Diversi studi comprovano che 2/3 dei progetti software terminano a causa delle stime errate definite a preventivo.
L’adeguamento dei requisiti con l’andamento del business e la complessità tecnologica possono essere, infatti, fattori di crisi che se non controllati portano alla chiusura del progetto.
Scrum è un processo di management e di controllo che adatta la complessità tecnologica al problema di business producendo parti di software rilasciabili nel breve periodo.
Ciò è possibile grazie all’inserimento nel gruppo di lavoro del concetto di “Social Engineer” e non di “Individual Engineer”. Scrum spinge la cooperazione al punto da creare il team e forzare l’auto organizzazione del team stesso.
Sarà il gruppo di lavoro stesso che deciderà la metodologia di sviluppo del software più conforme alle proprie attitudini.
Utilizzando Scrum il team produce in maniera incrementale ed empirica; il gruppo di lavoro è guidato dall’esperienza e dalla conoscenza globale piuttosto che da piani prestabiliti. Per questo motivo dove Scrum è stato applicato la produttività è aumentata in modo esponenziale.
 Project management practices introduce the coordinator of a project who’s main responsibility is to manage and facilitate the project flow removing any impediments. Agile introduces the concept of self-organizing teams, where all the people manage themselves.
Project managers iterate on a Planning sheet and even a Gantt chart updating information on it, while Scrum identifies a Sprint Backlog as a driver for the current sprint and the product backlog as driver for the project. While things are pushing with a rhythm, team is delivering and project manager is governing each situation everyone is happy and the project feels good; but, someone in the team can lose the control of what is being delivered. It doesn’t matter who is responsible for the matter, but the situation starts making all the rest suffering until crisis. This kind of problems emphasizes and become bigger time over time: like what happens in a domino.This can be still managed at last by the Project Manager that will solve the problem removing any impediments. But, what happen when the domino starts from the Project Manager or involves the Project Manager too? This is a case of the unreliable management, where the perception that a problem is occurring is not emerging and emerges only when the entire project is failing. Traditional software management practices tries to solve this problem by creating an hierarchy inside teams, where on top resides the project manager, than the team leader, and then all the others.
The team leader is clustering around the project manager to maintain good health for the project. This is a good way to establish a balanced monitor in the team management staff. But, what happen where the cluster is itself not reliable? Well, the domino effect occurs again. Agile software development is addressing this lack by promoting the entire team as a project manager and bringing a way to share daily a snapshot of the project feeling. A Sprint backlog is the driver for an iteration (Scrum identifies a sprint as an iteration), a sprint backlog is written by all the team members and is estimated daily. Every day all the team’s player must re-estimate the work in progress with the hours remaining for the specified task, and every day the team must respond to the customer (in scrum is the product owner), on what they have done the previous day, what they will do in the current day and which is the problem they’re finding on their way. The daily meeting is useful for the team too, because they can observe every day the remaining work to do and they can start anticipating some problems.
What happen if someone in the team is exploding?
The problem is faced in two ways:
1) At least through conversation during the daily scrum, when the exploders is not able to commit a task because his problems;
2) Formally by watching the sprint backlog and seeing the team feeling is not so good. Estimated hours should decrease while the time is passing; if a team is not feeling good, the decrease speed can be less than the expectation.
A daily meeting involves, three actors: the scrum master (who makes thinks happening), the team and the product owner. Every day one of them, can feel how the project is going formally – through the spring backlog – and informally through the daily scrum conversation.
This is the way Scrum and more generally agile is avoiding the Single Point of Failure where a Project Manager and a Team Leader cannot perceive a project failure.
A good Project Manager will discover that she is already doing something similar with her team. Scrum is all about common sense and shares the experience in managing complex situation. The Sprint Backlog is the driver for the sprint and to gain benefits must be updated regularly daily.
The daily estimation can produce a graph (in Scrum called Burndown chart) that visually represent the hours remaining. This can be good to check with only a sight the entire feeling of the team.
 The title can be more appropriate for a Spaghetti Western movie but is appropriate in each situation pair programmer are surviving theirs daily’s milestones enjoying work and maintaining a good environment outside them. “Pair programming” is identified by two words: Pair and Programming. Every developer knows exactly what is programming, but a pair requires some confidence with humans too. In this post I’m focusing on the Pair word of Pair Programmers, analyzing some successful factors like the Rhythm while working.
Like two cowboys a pair must work with a single objective every day, watching each other and helping each other; the external environment is like the desert with rolling Joshua trees and with condors flying, waiting, and watching for the next lunch hopefully with someone “freshly died”.
Imaging all this with a Sergio Leone’s music that is creating a more characteristic environment, where the rhythm is perceived watching the movie and listening the drum.
Two developers are in the same situation: they help together in finding the best solution for the daily milestone and they need to find out a perfect rhythm.
Like in a movie, some of them are the principal actor, and the other is helping in surviving the scene taking care about the stress and trying to keep her safe from external interrupts.
The main actor in a pair is the one who’s typing on the keyboard and typically writing the line of code. In terms of development perspective the secondary actor has to discover bugs, to seek for documentation, to write documentation, to diagram, etc. While taking care of human feeling, the counterpart’s job is to help the principal coder in doing things including stress management.
She has to know when it’s time to take over and switch the scene acting as principal actor. The frequency of a takeover implies the actors to watch each other, taking care about the health of the pair and trying to keep it good every time.
This is reflected on the quality of the code produced: every scene is played by the less stressed developer. Thus, the other can relax a little bit helping the next small iteration.
In this post I’ve examined three intra-personal factors that help a pair in staying consistent and durable over time:
- Rhythm: developers play the scene and the rhythm too. Rhythm translates is directly related to speed team. Without rhythm stress increases in one developer and low commitment increases on the other side. This is against the milestone.
- Watch the watcher: developers should watch them as Person and not as developers; programming skill is confirmed line over line, and more humans’ behavior (like stress) can easily hide. Watch the watcher if you want to be watched, is a protection guarantee for every developer that would like to work actively in a pair preserving her health prior to the colleague health.
- Takeover when need: avoid to much stress exposure for your colleague? In software development stress is the first cause of low quality. Being the principal actor confuses the main developer and sometimes can drive to the wrong direction, then frustrating and then stress. When your counterpart is loosing her speed, grab the keyboard, and continue typing (of course at your speed). You’ll notice that this rapidly debriefs your colleague making her reacquiring her rhythm and then asking the keyboard again.
In a next post, I’ll discuss about the relation between rhythm and speed in software development.
Scrum is a self-managing techniques that help software to be packaged iteration over iteration over a set of business critical feature. The iteration approach suites well to implement and release bunch of feature ready to be launched to the market. In mondora we focus on a Perpetual ß tool that helps us in finding and maintains the right path for the goal.
In mondora we’re working with Scrum for several years, and we find it useful to log and organize on a sheet: the process, the actors and the things produced iteration over iteration. This helps me and all parties during the development how us in mondora are approaching industrial software development: in a really open way.
The archetypes we produce are refined iteration over iteration; for example, while discussing the Sprint at the Sprint Planning meeting we try to figure out how the next feature implementation will fit on an architecture and we will produce some architectural document.
A set of feature is committed for a sprint, and the industrial approach stages directly the alfa version during development time. Because we’re working on features, we’re focusing on statement that creates value and at the end of a Sprint we’re ready to launch them as a Beta feature.
This happens iteration over iteration.
This only because Agile focuses on the idea that everything in a sprint is “something potentially shippable.” We then stage the next sprint and fix all the bugs in the prior consolidating those beta services as stable services and releasing new beta services.
This happens Iteration over iteration.
Every time, every day we’re looking at our Perpetual ß scrum sheet tool to know how, what e who is involved in the process and which will be the delivery. Of course, our tool is in ß too, and is growing day by day.
Tool is available to download here: mondora-perpetual-beta-scrum
Nowadays companies are thinking to promote a social graph inside the corporate instead of hierarchies. This is common to agile practice where all the developers together are the project manager.
Agile Manifesto and 2.0 approach have something that sounds really similar: people. People are the key in both Agile and in Enterprise 2.0.
Agile Manifesto outlines how project will be managed in a more conversational way, where values are the driver in software development. An enterprise 2.0 is focusing on people too, where a company’s seen as a multitude of people that are working together, having a relationship that helps the system growing.
 Currently companies are focusing on process and tools over comprehensive documentation. Currently companies are following a plan that enables negotiation between Customer and Provider.
Agile shall make companies focusing on individuals and interactions. Agile focuses on working software that is responding to changes. Agile establishes Customer as a Partner through collaboration.
 The enterprise 2.0 shall make companies focusing on relations between individuals and interaction over essential documentation and a fully functional company. The Enterprise 2.0 is responding to change and establishes Customer as a partner and colleague as a Friend.
Enterprise 2.0 focuses on adopting similar values expressed by the Agile Manifesto to corporate where the delivery is the corporate itself and not only software. Corporate, like Agile management techniques, trusts on human ability to create and maintain hi-value relations.
Both of the two mentioned approaches create a more conversational environment where colleagues/developers/partners can share their opinion their problem each other. Informal relations are brought forward to formal relation, where the main opportunity is to evolve something together.
I’m just back from a training about Agile and Scrum and one question made from an attendee was:
“You said it’s hard to success in a big project without implementing small iterations; I’m skeptic about it. How do you manage big time line as short-term iterations?“
Think about the Pareto Principle also known as the 80-20 rule that states that 80% of the effect come from the 20% of the causes.
Currently Agile is addressing that development effort should be spent only on the business direction: you need to implement something that is really valuable for the customer. This states a feature driven’s approach instead of others where everything starts from a feature, and everything ends when the feature become something potentially shippable.
From the Pareto Principle:
the 20% of features implements the 80% of business
In a Project, big 100 the investment is 100 a the total of returns are 100.
From an economical point of view results are reached and the mission can be thought as accomplished.
Watching it in a different perspective thinking that the 20% of efforts (energy/investment/etc) gives the 80% of benefits, we can think that the effort for getting the 20% is higher than the benefits.
By splitting 100% into five pieces
Different benefits could be gained:
- after 20% of time the 80% of ROI is collected;
- after 20% of time investment could be re-planned in a more flexible way
- after 40% of time the 160% is gained (more than the 100% of time in the previous approach)
- after 100% of time 400% is gained
Finally, product and business grow together iteration over iteration requiring that feature must be ordered having Return Of Investment in mind and having the most important feature for ROI implemented first.
Pareto principle involves a feature oriented iterations in thinking business and in approaching a development strategy.
 I’m just back from my training course in Florence with the intuition on why empirical Management works. Yes, it’s true. I figured out a simple explanation on the reason of it. Before giving my impression I would like to present an exercise I proposed to my attendee to help them in having confidence on estimation. They come from the same area, and they really know well what is there including best ways to drive in when there’s traffic congestion. I’ve started creating a Product Backlog having four routes to cities around Italy and requesting them to plan where they can bring me in 30 minutes. I’ve prioritized all the routes in the way. The first is really understandable, and the last is an Unknown City for them. Having it on the backlog I’ve started asking them which of those features can be implemented in the next 30 minutes. Consciously they’ve chosen the first feature. Before analyzing the Sprint Backlog of the selected featured with them I tried to do an Experiment about the Empirical Approach. To do this I’ve given a complexity rate of five points priority to the first feature and asked them to rate all the requested feature without thinking to much. Exercise took 3 minutes. - Second complexity was: 15 points of complexity; - Third complexity was: 25 points of complexity; - Fourth complexity was: 45 points of complexity. Having the feeling they can do five complexity each “sprint” I assumed a team velocity of five points of complexity per sprint. This mean that: - Second feature is approximatively estimated three sprints; - Third feature is approximatively estimated five sprints; - Fourth complexity is approximatively estimated nine sprints. Well the possible feature I asked them to estimate was the four cities I’ve touched coming back home and they gave me a reasonable idea of how many time or sprints it takes to get back. The surprise is that, even the team doesn’t know some of the place (third and fourth), they did a reasonable plan making me think that from Florence to home it takes 4.30 hours. Well it has taken 4 hours and 15 minutes. The magic is they’ve said 45. Why they haven’t said 100 or 1000 or 10000? This empirical approach work because, there’s no machine, no algorithms that predict things. There is a key element that is a Sum Of Super Computer that is the group and their brain. They did the estimation thinking about their experience discussing each other and sharing knowledge. They superiority – in respect of computers and algorithms – is the ability to think by metaphors and to regulate optimistic and pessimistic position in an intelligent discussion. Becoming familiar with estimation like this need time, than experience. It was the first time they did an empirical estimation and they still think there a sort of trick behind. It’s shocking how could be easy to give a projection on how things empirically will go. Every sprint they will commit their velocity, and every sprint their knowledge increase making complexity simpler and having things optimized on the experience.
One of the worst thing is when you’re facing a customer with no idea which feature must be implemented before the others.
 The question is, how can I help a customer in figuring out the 20% of feature is doing the 80% of business each iteration and sprint over spring she realizes the most important feature for the next iteration. At beginning, I’ve started asking to complete on a basis of 10 points. Each feature where 0 is the LOW priority and 10 is the MAX Priority. After raw estimation on how complex is the feature, I figured out an ordered Product Backlog with lots of MAX priority feature and the priorly implemented are the minor complex one and then move again. With this approach, I discovered there’s no rationales on the Product Owner side to decide what is really need priorly. Well, after lots of thinking I’ve tried to formalize a mechanism that push the Product Owner to think about the Benefits on having the feature and the Penalties on not having it. With this approach, I’ve pushed the Product Owner mindset from a selectable option to a selection on consideration. When thinking, I found an Algorithm similar to the “Wiegers Relative Weighting Approach” where I computed which is the less complex feature with major benefits and minor penalties. Three variables influence the priority:
- the Benefits of having the feature;
- the Penalty of not having the feature;
- the Estimation (I prefer Complexity – but is another thing) of the feature
The priority is computed on:
priority = [(relative benefit + relative penalty) / (sum of relative benefit + sum of relative penalty)] / ( relative estimation / sum of relative estimation)
The bigger priority is the most important feature in terms of easiness, penalty, and benefit. In this way, I discovered that Product Owners put in an ordered way their Feature List.
Endnotes
It is useful to work with this approach on attributing priorities. Product Owner works on the Product Backlog and integrate the new feature with this approach and reorder them. This is how a team should commit on a bunch of feature that is really valuable for the Customer.
In the next 2 weeks, I’ll have to present Scrum in a Scrum Session in Florence. I’m thinking to focus on kinds of management Scrum can do:
- formal side where task are clearly identified at the beginning, clearly estimated and clearly track in a day by day basis having all the Scrum Archetypes delivered;
- process side where all the parties involved in Scrum become active parts in a production chain, having the all the Scrum Events implemented;
- informal side having a way to address how relationship works and influences works
Formal and process is addressed by the Scrum methodology having the right role working with the right criteria and following the right Objective. There is ton of documentation explaining how to build a Scrum process in an organization.
Working since several years with Scrum as a Scrum Master and watching team deep dynamics, I’ve found that burndown chart can reveal more than the status of the delivery.
In modern project managing techniques, project is only managed watching Gantt diagram having relation between phases connected. On the Gantt bar there’s no confidence on how really the project is going; this because feedback is managed by a stakeholder, typically a project manager, and are not managed by the team.
Stress in the same way is not addressed letting team to self organize without a Criteria and having it emphasized last at the end.
By self-managing, a team is planning in terms of hours how the sprint will be conducted in terms of task to be accomplished, of issues and of assumption.
By outlining a Sprint Backlog where members some hidden information can be revealed. I think Stress is one of those.
Stress like other “energies” is something that, consciously, a team spends to accomplish a Sprint Goal.
The total amount of hours identified at the sprint planning meeting can be thought as the energy to be spent and energy focuses on pressure and pressure focuses on stress.
So a burndown chart can be seen as the project addressable stress, and an ideal curve from the beginning to the end of the sprint should be the ideal leveling of stress during days.
A Sprint Backlog task is coming from a prioritized Product Backlog; the first task refers to the most important feature to be implemented and the more stressing feature for the customer point of view.
By anticipating stress resolution, stress decreases while each task is done and each feature is completed. The next feature is less “important” than the previous with directs implications on stress.
A scrum master should point out that having a
- product backlog prioritized
- sprint backlog discussed in terms of hours (4 to 10 each task)
- daily scrum
- daily updated Sprint Backlog
is not addressed only the delivery of the project, but it is delivered the consistency of a team in term of psychological health.
I’m not a psychologist, but I’m searching a way to improve team day by day living to work better in a stress free environment.
Endnotes
The team is focusing on Phase Archetypes because they continuously increase focuses every time on what bring them out of burning. Common Objectives are lost against Phase Objectives. Without the right priority and without the right self-management strategy, team is move to do fancy stuff at the beginning and run faster at the end spending all the energies, creating pressure and then moving to a negative environment.
|
|
|
