Over the past few years, going back since 2004, when I first started working in an agile-like fashion to present day, I've seen companies and teams transform their development practices, maintaining a strong desire to continuously improve from past experiences. I've seen such transformations driven top-down (where senior management saw inefficiencies with existing processes, accepted a step change was needed to survive growth challenges and thus set about a strategy to implement new processes). I've also experienced the change coming from within the team themselves, experimenting at first (in the background), proving the value added to not only the local team, but to the wider organisation as a whole (although it wasn't easy, it is generally harder to influence bottom-up).
In order to derive some success from these transformational initiatives, there is usually a person who takes on the role of catalyst or driver, maintaining a clear vision of the goal and desired outcome - keeping people together, constantly reinforcing the message, always constant reminding. Generally this person is energetic, evangelic and carries enough of an aura for people to just believe & follow, the mark of a true leader. This is also made possible by having a team that has been through the mill, have battle-scars to show for it, and are really sincere in adopting the new strategy.
But what do you do, when you have a relatively young development organisation, cobbled together from various parts of the world, all differing skill levels & competencies, and when the leadership is lacking (incoherent) such that no one in the department has ever delivered a project successfully using Agile/Scrum before, have never really seen the development, people & cultural transformation required to realise the change from start-finish, and not have had the patience & privilege to live the agile journey of a few years??
What do you do when a team of aspiring young engineers that are just starting out on delivering formidable, real world-class products for the first time, who have been used to the heavy-handed old school project management styles of yesteryear -- suddenly fall in love with the premise of Agile -- but unfortunately lack the depth and breadth of understanding the real challenges of software engineering (product development, not proof-of-concepts)??
In the business of Set-Top-Box software product development, this is the software that provides your TV services like Personal Video Recording, Video On Demand, Linear TV, Electronic Program Guide, etc. A mixture of hardware design, low-level drivers, middleware operating system & high level user interface. Technologies are Java, Flash, HTML5, C/C++, embedded environment. This space is becoming highly competitive, how do such software providers remain competitive??
The answer generally touted is "We're adopting Lean/Agile/Scrum - we deliver fast, work with a rapidly changing market, flexible & practical" principles for product delivery -- but in reality ain't that easy - Agile adoption is a journey of at least three years, including time for experimentation & failure - it doesn't happen overnight. Some foundations need to be in place, principles that become the substrate for the future - a team without these foundations is operating in chaos, or as they say "Paying lip service to Agile"...
In this post I provide a straw man around goals that a development team could strive for in their quest for Agile. Just as they teach you in business school, that you need to have a plan guided by a mission, vision, strategy & plan of action -- so too can a development team ground themselves around goals that are SMART (Specific, Measurable, Attainable, Realistic, Timely). Moreover, if a team can latch onto some Real, Tangible, Concrete, Credible messages, these can be quite powerful in galvanising the teams around a singular purpose:
Straw-man goals to drive Agile Development
Defining a simple, tangible Vision that teams can relate to
Everyone should be aware of what your department is aiming to achieve. Posters, dashboards, etc should be highly visible and plastered everywhere, including stand-up spaces. These strategies shouldn't be left up to a specialist process improvement forum to manage in isolation (QA/Process Police). Of course, such goals should come from the team members themselves, but remember the situation: if the team is young, you as the dev manager should preempt the learning by promoting the use of established practices that have been proven by the global development community. Sometimes management interventions can be a positive force...
Vision/Goals should drive Implementation
To the well seasoned agile eye, the examples cited above might seem like a no-brainer to the point of being a ludicrous exercise of writing these down as concrete goals to focus on, after-all, these are stock-standard development processes, right?? Not so, remember when pitched to a team that have never seriously considered such ideas before, it will take some getting used to, and a lot of selling will be required, especially when the mentality of "if it ain't broken, don't fix it" exists. Typical implementation topics that spring to mind, would be:
Back when I was a developer, the company rolled out a Global Software Development Charter for the entire organisation to follow. We had over 2500 software engineers, multiple teams, spread across the world, different business units & of course conflicting cultures. So the Charter was kept at quite a high level, but clear enough to provide a broad-based framework to allow some kind of structure whilst staying clear away from detailed implementation, methodologies & process -- principle-based. All teams would provide their own self-assessments to measure progress & capabilities. The cool thing with the Charter was that it wasn't imposing at all, fitted in quite well with almost any development philosophy.
For young development teams, a charter like the below example could be a useful starting point:
But what do you do, when you have a relatively young development organisation, cobbled together from various parts of the world, all differing skill levels & competencies, and when the leadership is lacking (incoherent) such that no one in the department has ever delivered a project successfully using Agile/Scrum before, have never really seen the development, people & cultural transformation required to realise the change from start-finish, and not have had the patience & privilege to live the agile journey of a few years??
What do you do when a team of aspiring young engineers that are just starting out on delivering formidable, real world-class products for the first time, who have been used to the heavy-handed old school project management styles of yesteryear -- suddenly fall in love with the premise of Agile -- but unfortunately lack the depth and breadth of understanding the real challenges of software engineering (product development, not proof-of-concepts)??
In the business of Set-Top-Box software product development, this is the software that provides your TV services like Personal Video Recording, Video On Demand, Linear TV, Electronic Program Guide, etc. A mixture of hardware design, low-level drivers, middleware operating system & high level user interface. Technologies are Java, Flash, HTML5, C/C++, embedded environment. This space is becoming highly competitive, how do such software providers remain competitive??
The answer generally touted is "We're adopting Lean/Agile/Scrum - we deliver fast, work with a rapidly changing market, flexible & practical" principles for product delivery -- but in reality ain't that easy - Agile adoption is a journey of at least three years, including time for experimentation & failure - it doesn't happen overnight. Some foundations need to be in place, principles that become the substrate for the future - a team without these foundations is operating in chaos, or as they say "Paying lip service to Agile"...
In this post I provide a straw man around goals that a development team could strive for in their quest for Agile. Just as they teach you in business school, that you need to have a plan guided by a mission, vision, strategy & plan of action -- so too can a development team ground themselves around goals that are SMART (Specific, Measurable, Attainable, Realistic, Timely). Moreover, if a team can latch onto some Real, Tangible, Concrete, Credible messages, these can be quite powerful in galvanising the teams around a singular purpose:
Straw-man goals to drive Agile Development
Consider this situation: You, as the Software Development Manager have invested time and money in sending your people on training courses to learn about Agile/Scrum. You've attended the popular conferences, even got a few engineers converted to Scrum Masters, sent them on Certified Scrum Master courses. You went to the extent of bringing in highly acclaimed Agile coaches to learn what other companies are doing. You've invested in tools to support the development processes. Your teams appear to be implementing Agile/Scrum, by virtue of performing the Scrum ceremonies - but still, things appear disparate, disconnected and joined-up focusing on a common, clear & unambiguous direction! You find it quite difficult to measure productivity, gain any confidence in the value being created, and not confident that every build/release brings with it an increase in quality.
So why not consider creating some goals?? You could start with comparing your team to other companies with a proven agile strategy:- We want to be like BSkyB - deliver cool feature upgrades more than twice a year
- We want to learn from Apple / Google - how do they deliver frequent upgrades one-after-the-other?
- Remember Einstein on "Insanity - doing the same thing over and over again and expecting different results"
Expand on Goals / Development Charter
- To learn from mistakes of the past, not to fall into legacy release cycle mentality
- To release fit-for-purpose software to customers in-field every three months
- To have no more than three tries at release candidates to produce a Launch build
- To have a continuously stable development, integration & test stream such that a build of shippable quality can be made at any given time
- To aim for Zero Regressions on a daily, if not weekly basis
- To deliver small increments of functionality that adds real value, zero regression, in regular cycles (three months)
- To cut down the number of QA/Test cycles required for any release down to ONE week
- To reduce the amount of manual testing effort for any release such that the test team is no larger than five people
- To automate every functional requirement test as far as possible such that the health can be tracked on a daily basis
- To automate all core performance & stability requirements as far as possible such that we don't introduce a bad user experiences from the last upgrade
- To be serious about value added metrics including code quality, stability, performance & user experience
- To settle on a process that offers better prediction for planning & estimation of release milestones
Everyone should be aware of what your department is aiming to achieve. Posters, dashboards, etc should be highly visible and plastered everywhere, including stand-up spaces. These strategies shouldn't be left up to a specialist process improvement forum to manage in isolation (QA/Process Police). Of course, such goals should come from the team members themselves, but remember the situation: if the team is young, you as the dev manager should preempt the learning by promoting the use of established practices that have been proven by the global development community. Sometimes management interventions can be a positive force...
To the well seasoned agile eye, the examples cited above might seem like a no-brainer to the point of being a ludicrous exercise of writing these down as concrete goals to focus on, after-all, these are stock-standard development processes, right?? Not so, remember when pitched to a team that have never seriously considered such ideas before, it will take some getting used to, and a lot of selling will be required, especially when the mentality of "if it ain't broken, don't fix it" exists. Typical implementation topics that spring to mind, would be:
- Conduct proper code reviews
- Refactor code regularly
- Write comprehensive unit tests - test the code as well as functionality
- Implement Test Driven Development, at all levels, realistically
- Gather relevant metrics
- Pair programming
- etc
Back when I was a developer, the company rolled out a Global Software Development Charter for the entire organisation to follow. We had over 2500 software engineers, multiple teams, spread across the world, different business units & of course conflicting cultures. So the Charter was kept at quite a high level, but clear enough to provide a broad-based framework to allow some kind of structure whilst staying clear away from detailed implementation, methodologies & process -- principle-based. All teams would provide their own self-assessments to measure progress & capabilities. The cool thing with the Charter was that it wasn't imposing at all, fitted in quite well with almost any development philosophy.
For young development teams, a charter like the below example could be a useful starting point:
Group R&D Charter
Project Start
- Projects will have a Software/Hardware Development Plan that meets a defined schedule according to the customer's needs
- Projects will have a Test Strategy
- Projects will have an Integration Plan
- Project will have a Risks Register (baselined at Kick-off, managed ongoing)
- Projects will have clearly defined Roles & Responsibilities
- Projects will agree on the strategy for re-use at Project Kick-off (Requirements, Design, Tests & Code)
- Project strategic milestones will be agreed upon at Kick-Off (Incremental deliveries, Integration Points, ATP, etc.)
On-Going
- Projects will follow a realistic Resource Allocation Plan
- Requirements will be documented/Managed/Reviewed depending on customer's needs
- Designs will be Documented and Peer-Reviewed
- Code will follow a coding standard
- Code will be peer-reviewed
- Builds will be automated and repeatable (ESCROW by default)
- APIs will have a tool by which they can be tested
- Continuous Integration & Regression Testing will be adopted
- Test Driven Development will be adopted
- Static code analysis will be in place
- Leverage Open Source Tools & Code as far as possible, respecting Licence rights
- A Suitable Automation strategy will be in place at all levels of component & systems integration
- Defects and Issues will be tracked and will undergo Root Cause Analysis
- API change control process will be implemented (deprecation rules, backwards compatibility)
Outputs
- Project / Product artefacts will be held within a configuration or document management systems
- Release builds will be controlled and always traceable back to source
- Demos will be held regularly with customers focusing on full stack end-to-end features
- Projects will have end of project reviews
No comments:
Post a Comment