|
From bright ideas to business solutions it is a long way and we all know that the best measure of success is progress. So we need to answer the following requirements:
1. You need to go FAST!
2. You need to go FASTER!
3. You need to be the FASTEST!
There is nothing wrong with this approach from the business point of view. Good time to market means “competitiveness” and sometimes even “continuing to exist”.
But business is also about remaining competitive on a long perspective and when it comes to software development this could have a major drawback. You’ll have to adapt, improve your solution, insert new features so that you gain more share and benefit or just to remain on top. This is where “faster is slower dynamics” apply: your enterprise application doesn’t scale up, you need to add a mobile application but you didn’t thought enough, your application is not stable or secure and now it seems that separation of concerns was doubtful respected. The main topic around the development team is technical debt and they insist on rewriting/refactoring the application. Never felt that? Ok, you can still read my post so that you’ll diminish the need of quick and dirty in your future implementations.
There are lots of reasons you may encounter similar situations but most of them could be treated or at least identified and planned in one particular phase of the project, probably the most important one: project preparation phase. This is where I and my pool of experts share a very important mission in Pentalog: assisting the client and his team in making the best choices and treating also those concerns that the entire organization may not be aware yet.
After almost 2 decades of experience in launching IT projects, Pentalog proudly announces the appearance of “Start me up!”, a complete framework based on a subset of components:
1. Team calibration
2. Project feasibility
3. Manufacturing
4. Continuous improvement
Depending on your needs you may choose which subset fit you the most on your future projects.
Starting from project goals to skills management, within team calibration framework, during project launch, you can achieve skills map, team evaluation, organizational chart, integration roadmaps and trainings. If you work already with People Centric, most of the team evaluation part should be already done. In average the length of this phase is 2 days.
Everybody should understand the benefits of products and services! Therefore the entire team, from business stakeholders to software engineers, need to have the same vision on these benefits, and we enhance that within one of the core components of project feasibility framework, called business value framework. Together with risks management, wastes checklist, visibility, planning and estimation tools, around 3 days in average, should help you determine at this early stage the feasibility and major obstacles you have to treat with greater priority. At your wish, we can go even further into architecture review, establishing rules for you, the tests strategy and so forth.
However, launching a software project on good premises seems to be a pretty big phase against agile philosophy where you try to keep the Sprint 0 shorter or equal to the standard sprint size. Here some insights: preparing a continuous integration environment takes from 1 to 5 days, deploy other management tools like for planning, requirements management, quality centers, collaboration tools… again between 1 to 5 days where engineers with different profiles must intervene.. Worst of all is that these tools evolve fast, and you should try to use well tested technology on your projects. How to keep track of all that knowing you have to work on your projects? We are continually doing it by collecting an important amount of data from real projects, so you can benefit when we are building together the basis of your projects. Inside Pentalog it is called Production Fabric. We are able to deploy them fast and easy in our private cloud environment and in less than 1 day we will also configure them, so that it will completely fit your needs. All this is being apart of Manufacturing Framework.
Now let’s look on a representative survey regarding the project preparation phase:
Why representative? Because none of the companies I’ve came into contact with is doing less than 2 weeks for this phase.
With us, you can do it in 1 week. Is that fast enough for you?
To ensure that the organization complies with what you have already defined and adapts it progressively and continually so that you can deliver more business value to your clients, the 4th framework should apply: Continuous improvement. During this phase we integrate a minimum set of practices and tools into your development process and a series of events so that improvements occur. By events we understand from knowledge sharing events to audits. We show you how to do it or we can do it for you. Now you are on the runway, as before, just that this time you know you are on the right one, you benefit from the experience of hundreds of projects and your are between 2-4 times more efficient than before.
Want to see how fast you can get?
“I had difficulties respecting deadlines and products were flooded with defects and bugs, which made it even more difficult when accepting changes required by the customer until I decided we have to step into agile world! In Scrum they accept changes diminishing impact because there is no document to update. The team is self-organizing and more responsible so we will have fewer defects in the end. Traditional development models are no longer sufficient or effective.
6 months after software manufacturing with Scrum, we understood that all this was just good advertising and worst results were just about to come!”
Does this desperate message sound familiar? Yes, too familiar! As a CTO at Pentalog I had the opportunity to meet potential clients with similar problems: “we’ve done Scrum but it doesn’t work for us, so we want to continue in a more traditional, waterfall or v-cycle way…” When this comes to my ears I never react. Maybe they found a context where Scrum does not apply. During further investigations it turned out that Agile practices were not sufficiently mastered or even not applied. Causal analysis showed that it was not related to organizational models, delivery issues…, but more likely about wrong beliefs, agile misconceptions and local optimizations.
Migrating from traditional product development to Agile way requires a different mind-set, enabling us to completely deploy and understand the deep changes that must occur! Resistance to change will overwhelm your enthusiasm, will delay ROI and you’ll come to the same conclusion in the end: “Scrum doesn’t work!”
Staring at the Agile world with the eyes of an experienced agile practitioner is almost impossible for the beginner. Because common sense is not the same for everybody, less experienced people will interpret “Working software over comprehensive documentation” as “we no longer need documents!” and we can’t transform into self-organizing teams over the night, can we?
So, how can “we solve our problems with the same way of thinking we used when we created them?” Albert Einstein. You can’t! A good approach would be to start by training people for Agile practices with trainers outside your organization. A training for Scrum usually takes around 2-3 days, is very efficient but it’s still not enough. You should prepare for a long run. This is where the role of the Scrum Master takes its place. He is there for you to facilitate all that and to ensure that everybody from the organization respects established and agreed values. Be aware that a project manager can’t implicitly be converted into a Scrum Master ! It will require a lot of training and coaching for him too so that he will change his reflexes from a manager to a coach and facilitator. Once again, try to find a more experienced Scrum Master (Agile coach) who will guide you for several months.
This is not an easy explanation for the Board: “We’ve bought the best managers money can buy, and now you’re telling me they are not good? What are they going to learn during this training? What are the benefits?”
An Agile course should be adaptive. From our experiences, in order to cover the most important aspects of Agile development and Scrum, an entire team would need around 5 days of training.
- 2 days for all the team (Scrum Master and Product Owner included)
- 1 day for Scrum Master
- 1 day for Product Owner
- 2-3 days for the team members regarding agile manufacturing (testing, developing, continuous integration…)
During this training people should understand:
- The differences between traditional software development methodologies and Agile development. When does Scrum apply? Avoid ScrumBut!
- What is business value and business attitude?
- What is wishful thinking and how to eradicate it? Estimations, planning (planning poker), team velocity.
- The different perspectives of building an environment for increased shared understanding (self-organizing teams, team welfare, coding standards, definition of done, simple metaphor, simple design)
- What about self-organizing teams?v
- Agile VS Discipline! Scrum ceremonial.
- Agile testing (test everything, TDD, Mocks, A-TDD, GUI acceptance testing…)
- Pair programming, refactoring (hiding, extracting…), code smells…
- The importance of feedback (continuous integration, frequent delivery)
- Scrum is a continuous process (continuous improvement and learning cycles, retrospectives, impediments management)
- How to continuously improve results in order to bring more value to final clients? Diminish waste!
- Learn to unravel system dynamics, root causes, mental models and local optimizations.
Regarding the second question, maybe the most important one “What are the benefits?”, Scrum is often seen as a cost saving measure for the companies by being focused on business value delivery, product adaptability and time to market. Reports like “The Standish Group’s statistics on software usage” confirm the importance of having a value driven development approach to decrease the number of unnecessary features:
Also known as the Pareto Principle, the 80-20 rule, the law of the vital few and the principle of factor sparsity states that for many events, roughly 80% of the effect comes from 20% of the causes. This is why an Agile team shall continually ask what incremental value a new feature will deliver over another.
Our experience shows that in the first semester you will earn between 25%-50% in productivity if you are already aligned with an international standard like ISO 9001:2008 and after 2-3 years of continuous improvement with Scrum, the gain can raise to an astonishing 100%-200%.
It requires a lot of courage for your team to achieve that, but we will see more about that and Scrum values in future articles.
|
|
|
