December 14, 2008
Filed under: Agile, Events, Teams — Aldo Cauchi Savona @ 11:05 pm
This post is an overview of my talk at the December 2008 AgileMalta conference. It is slightly oversimplified, but there is only a certain amount one can say in a blog post 
I hope that this post will help you get more value from the talk slides. My main interest in Agile lies in the area of Process Facilitation and Team building. It is my opinion that the greatest investment a company can make, is to improve the quality of its workforce and in the creation of one or more Teams.
The presentation is based on the following observation: A team is inherently dysfunctional.
It is common knowledge that the greatest ‘resource’ of a company is its workforce. Also, the quality of these ‘resources’ has a major role in determining the outcome of a company’s projects. From a traditional approach, the idea of quality lies in the skill level and the experience the ‘resource’ has. The focus is mainly technical. The person is viewed as a ‘resource’, a replaceable part, a concept that stems from the idea of specialisation in the manufacturing industry (see Implementing Lean Software Development: From Concept to Cash, Mary & Tom Poppendieck, 2006).
The focus of attention is also on the individual. Most of our progress (from school to work) is measured on our personal ability. We have personal reviews with our managers who give us personal targets to reach in order to attain a new level in our career or change our pay-scale.
The talk also delves into a bit of psychology with regards to the evolution of the Ego… Over time (past couple of centuries) people developed an Ego and psychologists say that it has now reached its peak. By ego I refer to the psychological notion which allows us to say “I” or have a concept of “self” (see The Archetypes and the Collective Unconscious (2nd. ed), C.G. Jung, 2002).
As such we can say that, due to our individuality, we are naturally dysfunctional within a team. Companies further promote dysfunction by focusing on the individual.
In the presentation I also make a common distinction used in Agile between a Group and a Team. A Group is the most common setup within companies. Each person in the group has a particular area of expertise, role and responsibility. While working on the same project they are working towards different targets (namely, the ones set by management).
In contrast, a Team happens when each person in the team is moving in one direction. From an external point-of-view, the team is a single entity with one goal.
In team-building exercises, attendees are often shown an image of synchronised rowing. There is also a common cheesy poster I saw in a three companies I worked for with such a photo and the title “Teamwork”. However, when we set individual targets, each person is offsetting the rhythm of the group hindering the speed at which they reach their goals (see slide 10 in presentation). It is called synchronised rowing for one main purpose: each member in the boat rows to the same rhythm. The more synchronised the team is, the faster they reach their goal.
Should a company decide that they would like to have a team and not a group, it first has to realise that it is dealing with people that are more complex than a fixed ‘resource’. Also, since individual ‘treatment’ is not the solution, the next step to resolving dysfunction, is to decide on a single goal for the team. The decision is made together with the team and not for the team.
While the whole company is involved in creating the team, the emphasis is now on the team and it has to find a way to reach this goal as fast as possible. The team has the help of management or in Agile, the process facilitator, who helps them find the motivation required to reach their goal.
This is only the starting point. The common pattern that emerges is that individual traits that hinder development speed are brought to the surface. Other issues, technical or otherwise, that before were easily covered up are also exposed. The first reaction to this situation is usually a retreat to the safety of the past behaviour. This is where most teams fail. You will need to courage and persistence to surpass the difficulties that arise if you truly wish to reap the benefits of a team.
Click here to download the talk slides “Building a Successful Team”.
October 13, 2008
Filed under: Agile, Domain Driven Design, Technical, Test-Driven Development — Dave Sammut @ 11:53 am
Implementing Domain Driven Design – Creating a Stable Code base
This is the second part of my experience on applying Domain-Driven Design (DDD) on a recently completed project for a major blue-chip company. In the last post, I showed how by using DDD we managed to reach a consensus between the technical and business people through common terminology.
In this post I will talk about a more technical achievement that was possible thanks to DDD.
Given the tightly coupled nature of the application and the framework we knew it would be a challenge for us to create a true implementation of the domain model we created.
We decided to use our DDD concepts to create a Layered Architecture which allowed us to introduce the use of entity, value object, repositories, factories and services With this approach, different modules were created which were all assigned a behavioural responsibility. After several team discussions and hardcore development, we created an application framework which we were confident that it satisfied all the key areas of responsibility. This also meant that we application framework would be able to meet the key business requirements that mapped the code to the domain model.
Using this approach, gave us the benefit of having loosely coupled modules where each module adhered to their declared behavioural responsibility (high cohesion) and opened the door to a test-driven development approach. The key business modules and supporting modules had a good unit-test coverage which gave us a stable core code base to build upon (expressed through Interfaces).The framework, however, did pose some limitations and so we were not able to unit-test all modules.
The framework also had other limitations. Where possible, we introduced Interfaces for classes that lacked them and when the altering the original class was not possible, we applied the proxy pattern.
Our development was driven by User Stories. Using the Layered Architecture from DDD allowed us to focus on completing the development of one story at a time. This was achieved by ‘injecting’ dummy implementations at different layers which allowed for different areas to be worked on simultaneously without impeding development on separate layers.
Through the domain diagrams we managed to achieve:
- High unit test coverage of the core code-base,
- Abstraction from the framework to allow us to map the code to the domain model,
- Developers became familiar with the implementation patterns that emerged which sped up development,
- Developers found it easier to debug issues as they knew which module was responsible for what, and
- The technical team used the same business terminology to discuss the code-base.
In the next and final post on this subject I will share my experience of how DDD helped us meet our business and technical acceptance tests.
October 6, 2008
Filed under: Remote, Technical — Dave Sammut @ 1:19 pm
Implementing Domain Driven Design: Domain Diagrams – Dave Sammut
My team and I just completed a project where I believe that our knowledge of domain-driven design allowed us to complete an application based on a rigid framework with an aggressive time-to-market deadline. Unlike other web-applications we have made for the same parent project, this sub-site had a complex content model complimented with complicated business logic. The rigid framework we had to use had many page components with a long list of super classes which hindered any approach to a test-driven application development as the domain items (the business logic) was tightly coupled with the framework’s core architecture.
In this post I would like to show how the usage of Domain-Driven Design (DDD) allowed us to achieve our business goals.
At the beginning of the project, we received a set of documents that expressed the main business logic and the Information Architecture (IA). However, when we started to dig into these documents, we found inconsistencies with the business logic and the way different terms were used. In other words, there was no common vocabulary or agreement on business reasons for the requested business objects.
Having used DDD in previous projects, I took a stab at introducing my understanding of the application domain through the use of numerous diagrams. By application domain I mean the business logic, content models, object relationships, constraints, etc.
The introduction of a new process is always met with resistance and none was spared here. However, the diagrams sparked discussions and increased communication between myself, the technical architect and the business analysts. Through this process the I attained a deeper insight in the complex application domain which allowed me to improve the diagrams.
The domain diagrams became the necessary bridge between the business and technical people. Through the domain diagrams and their explanation, I could easily share the domain knowledge I gained while at the same time provided an easy reference for both technical and business staff.
Through the domain diagrams we manage to achieve:
- Created a common vocabulary for use by both the technical and business people,
- A deeper insight in the domain by the technical team,
- The discussions created a feedback loop through which technical limitations updated certain business assumptions,
- We established a better relationship between the business and technical teams which were located at separate locations, and this resulted in
- A shared ownership of the domain which increased team commitment and team optimism for a successful project.
Once the domain was understood by the technical team, a domain modeling session ensued which allowed us to achieve many technical goals and will be posted soon
October 1, 2008
Filed under: Agile, Teams — Aldo Cauchi Savona @ 1:42 pm
Earlier this week, I heard a comment by someone I was speaking to that they do not like Agile methods as they proclaim that the developers should not product any documentation or else, that there is no need for any planning. This was not the first time I heard this comment. One person exclaimed that when he worked in a company that used Lean practices, bad quality products were delivered thanks to the Lean practices they used!
Apparently, the people they worked with interpreted reduced documentation and planning for no documentation or planning. This gives rise to the view that Agile = Lack of Discipline = Bad Quality Products = Bad Process.
Anyone who has decided to dig a bit deeper into Agile and their theory would know that they are founded on two fundamental principles: Discipline and Quality. A great example where adequate documentation and quality driven development was used is the Boeing 777 project. Their aeroplane was ready for in-flight testing after 2 years of development, 3 years ahead of the norm.
If at the moment your team is not producing any form of documentation, or have a poor development development process, then when transitioning to Agile, you will most likely have to produce more documentation and do more planning than you currently do. When Agile practitioners talk about streamlining your documentation, they mean reducing the amount of documentation an existing cumbersome process might require. Again using Boeing as an example, the 777’s electronics specification document was over 2500 pages. When Boeing increased the collaboration with their provides, they could reduce their specification. The end result was that the 787 electronics specification document was reduced to 20 pages.
Agile methods ask all committed people to be more involved in the project, and to always act in the best interest of the project. This requires great discipline and dedication with the end result being a high quality product!
See: http://leadinganswers.typepad.com/leading_answers/leadership/;
Implementing Lean Software Development: From Concept to Cash by Mary and Tom Poppendieck.
September 18, 2008
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’.
