Filed under: Business, Enterprise — Aldo Cauchi Savona @ 12:38 pm
I had written this article in February 2008 after listening to a talk by Boris Gloger called “Scrum - A way to change enterprises” at the Agile Malta conference in February 2008 and discussed the subject with a DSDM practitioner friend of mine. The article a time in my experience with Agile where people expressed they idea that “Agile” is something for developers and not for any other aspect area of a software project or the business itself.
It is most likely that at some point in time you would have heard the words “agile” or “scrum” mentioned within the company usually when people refer to the way the software developers work. However, agility is not just about the way we do software development it should be about the way the company does business.
The Agile frameworks are based on a very simple cycle of think-act-do and implement a basic inspect and adapt approach to the way we currently do our work. What this means is that at regular intervals a group of people who are working to achieve a goal, be it a piece of software or reduce the number of open issues, discuss the way they are currently working and see what they can do to improve their current situation. Thus, Agile is about making what we do better.
Why would a company decide to adopt an Agile framework? Is it because Agile is trendy within many software development companies at the moment? Well, if a company simply made the transition to Agile for the sake of being trendy they would most likely suffer a decrease in productivity rather than an increase. After all, the transition to Agile is not quick and certainly not cheap!
Why? A company has a business goal; a vision of where it would like to be. The vision can be compared to an explorer whose goal is to explore the mountain on the horizon. This goal is assessed to be achievable. Now, what the company needs is to implement a model based on business values to reach its goal(s). Agile offers a flexible framework within which a company can reach its goals. So, a company will make the expensive transition from a traditional framework to an Agile framework because it believes that the Agile framework will help it achieve its business goals faster and more efficiently. In such a case Agile becomes the business model with which the company will achieve its goals.
For example, Toyota felt that the only way to compete in their post war environment was to reach a state where they have a minimal inventory and produce cars on demand. After around 30 years they perfected this framework and it was coined ‘Lean’. Using Lean, the company suffered minimal losses during the 70s (or 80x) fuel scare and in recent years, Toyota has surpassed General Motors in vehicle sales. Also, the Toyota Prius is an exceptional business case on how they understood market demands and product a car, from concept to production in less than a year.
Toyota managed this because agility is ingrained in the way they do business. For Toyota, Agility starts from the way they deal with their suppliers to the way they care for the end-consumer.
About two years ago, I worked with a great company that decided to opt for an Agile framework called Scrum. The first department to start using Scrum was the development department and we started the transition about 1½ years ago. The main reason why development was 1st targeted is because Scrum’s initial focus when it was conceptualised back in the early 1990s was software development and it was mainly focused on improving the collective output of teams.
This does not mean that only the development department can benefit from the Scrum framework. Many companies have adopted Scrum to handle their customer support and IT services too. At the 1st Agile Development Conference held in Malta on 19th February 2008, I met a person from an insurance company (I think it was Atlas Insurance but can’t quite remember) where they implemented Scrum principles in the way they handle claims to improve the way they work. The net result was improved productivity and reduced stress on the employees. Many other examples of successful non-development oriented can be found on the internet.
However, even if Scrum is implemented within individual departments and they each manage to improve individual department output, each department will still be an independent silo. This will prove to be a limit to the team’s output and the only way to get more productivity is to apply the same principles of Scrum that applied to a team to departments. The end result is that the business model will change, where, rather than have vertical individual departments (i.e. a traditional organisation hierarchy), you implement horizontal inter-department teams that strive to improve productivity on a ‘product line’. These teams will involve members from all departments relevant to the product, for example, members from the Sales, Marketing, Support and Development departments.
By having a member of each department that will have an affect on the product in one team, important decisions that can impact the company’s direction can be taken quickly. Also, the wishes of each department will be represented within a product line from the start. With this approach, inter-department commitment to a product will be stronger and more united. One major corporation that has gone through this restructuring programme is BT who gave a keynote presentation about their process at the November 2008 Scrum Gathering Conference in London (Scrum@BT).
A founder of a billion dollar company expressed the power of unity as “If you could get all the people in the organization rowing in the same direction, you could dominate any industry, in any market, against any competition, at any time.”
Aldo Cauchi Savona – Feb 2008
Filed under: Remote — Dave Sammut @ 12:15 pm
Certain themes become cardinal rules after getting through a year long agile project working on a proprietary framework from within a near-shore development team.
As happens with many lessons learned, there are weaknesses exposed and praise for what worked well. As also happens with lessons learned, much of these are forgotten or simply not put into action during the next endeavor. So here are some key points, cardinal rules if you will, and awareness of potential pitfalls awaiting a remotely located development team - Dave Sammut.
“No Surprises” - Radiohead
The importance of regular code reviews which include pattern usage, best practices, performance and stability. This could possibly include participation of a non-team member to participate during the sprint to audit code and provide feedback back into the team during the stabilizing period.
Pattern Usage - The use of standardized techniques to perform both application specific logic (business logic) and pluming (retrieving data, URL creation) processing.
Best Practices - Javadoc, formatting, common java best practices
Performance - Policy counts, performance analysis which feeds back into application specific (business logic) patterns used. Perhaps an IA/BA review needed
Stability – Unit test coverage, Integration test coverage based on user stories
“I believe the children are our future Teach them well and let them lead the way” - Whitney Houston
In any discipline, be it technical, BA, IA or testing it takes an individual with the right attitude and approach to ensure quality and success (knowing what to deliver) upon which management would like to model new people entering a similar role. The problem is what when a new individual enters the role, new attitudes and approaches (including new good and bad habits) are introduced which at times are not part of the ‘modeling’ result management desired. However, without diluting an individual’s personality, a suite of cardinal rules (a manifesto even) should be communicated to ensure that no matter what good or bad habits are introduced, the core basics which define success are ALWAYS adhered to. Failure to do so simply reflects an ill placed individual in a particular role.
“A wicked messenger falleth into mischief: but a faithful ambassador is health.” – The Bible
At each location daily communication is paramount to resolving issues and to gain further insight into the domain, which is then reflected in the code-base, an updated IA or business rule. This will then need to be communicated to the testing team to ensure verification integrity. Further insight into the domain is achieved when concise and efficient communication, through the use of a common vocabulary, proper tools and domain diagrams, is exercised.
Communication across geographically separate locations presents increased risks of miscommunication. When ill communicated (misinformation) solutions are implemented (code, IA, BA) the actual results of the ill communicated solutions will surface at a later date when the issue in question is no longer fresh in all the participants’ heads.
To minimize the risk of miscommunication, an ‘ambassador’ at each location should be responsible for the quality of communication, through the use of appropriate tools (IM, phone, WebX), discipline in communication (common vocabulary) and with the help of visual aids (domain diagrams) to further drive an idea home. It’s not that only one person is involved in all communication, rather the ambassador should be aware of the big picture and be able to assist team members be good communicators.
“Necessity is the mother of all invention” - Thorstein Veblen
From the moment an idea is endorsed and selected as a user story the detailed definition is produced. This includes everything a development team needs to successfully implement a user story; design, IA, BA, user cases and test cases. Some user stories require a great deal of detail depending on its nature, others require very little definition at all, or at least very little of a particular artifact. The idea is to have ‘enough’ information for the successful development of the user story. However, should further insight be required, other artifacts can indeed be created to explain the further insight needed. Using a guideline as to what is indeed ‘enough’ and further artifacts delivered upon request minimizes the amount of decay and unused efforts. Once again, depending on the nature of the user story, the teams should agree to what degree is indeed acceptable amount of information. Failure to understand what “sufficient information” is can lead the design effort to resemble that of RUP with a heavy up-front design phase.
“I see dead people.” - Cole Sear (6th Sense)
The importance of communication amongst team members and in artifacts is a paramount theme when working in geographically separated locations. Without the luxury of face-to-face communication that benefits from being within an earshot or ‘around the corner’, team members must turn to alternative ways to efficiently and accurately communicate with each other.
With face-to-face communication the talker and the listener benefit from gestures, white boards (physical and air), body language and instance acknowledgment of statements, ideas and arguments. When separated, team members need to heighten their other senses to ensure that they make up for the lack of face-to-face communication. Team members need to be made aware of what tools are available and how to effectively communicate across these channels. These channels require that communication etiquette be adhered to minimize frustration and promote such tools.
“Surround yourself with the best people you can find, delegate authority, and don’t interfere as long as the policy you’ve decided upon is being carried out.” - Ronald Reagan
It’s impossible or very tiresome exercise to micromanage every deliverable of every team member. Each team contains different tasks, different skill-sets, different people with different ambitions with whom all tasks must be addressed. Each team member can indeed be strategically positioned to exploit their skill-set and can be used to attain new skills from different members performing different tasks. The art of cross-pollination ensures that no one person holds the information by which in their absence the team is presented with an impediment. This coupled with strategically positioning team members in roles which exploit their skills will create a well-balanced team and a skill-building team culture.
“Individual commitment to a group effort - that is what makes a team work, a company work, a society work, a civilization work.” - Vince Lombardi
On the whole the project is seen a one team divided into separate sub-teams which are all required to deliver artifacts (deliverables). Each team in this configuration can also be divided into other sub-teams. So, essentially there are two configurations which need to be addressed to minimize risks such as miscommunication and poor quality of work.
The two sub-team configurations:
- Co-located
- Distributed
Co-located sub-team
Co-located teams benefit from ease of communication amongst themselves to collaboratively produce their deliverables. The challenge such a team has is that of producing deliverables which concisely communicate sufficient information for other teams to use to fulfill the production of their deliverables. The risks the team has to deal with are indeed producing ‘just enough’ of information for other teams. Should another team require further insight, this request should be handled by the co-located team and addition information supplied to address any shortage of information. Basic rule is to know what exactly to deliver by adhering to a set of cardinal rules/guidelines.
Distributed sub-team
Distributed sub-teams have the same responsibilities as co-located teams with the additional challenge of team members located at separate locations. This adds additional risks of miscommunication of ideas finding their way into the final product thus resulting in a deliverable of poor quality. Such teams must establish efficient means of internal communication and an appropriate quality assurance measures.
No matter the configuration of a team, miscommunication (resulting in poor quality deliverables) can find its way into any facet of the deliverable. The only difference is that the less importance given to communication in either team will have different severity levels of repercussions.
Team Audits
Each team, regardless of discipline should be subject to regular audits on all deliverables from the different target audiences to ensure that the deliverable does indeed sufficiently communication clearly to all related parties. With additional efforts given to inspecting the quality of deliverables prior to their ‘sending off’ catch any potential issues before the producing team deems the deliverable to be ‘done’.
