Agile+

Note: This blog post transferred from my OLD BLOG and was originally posted in 2009.

Almost more than 3 years since i’ve been part of projects run by Agile, i had the chance to participate it in different roles and places in the whole project lifecycle,  starting from software engineer passing by being an Architect, Business Analyst, Team leader, and finally a Project Manager. It was absolutely a long journey with good, bad experiences, joyful, sadness, difficult moments, hard situation, stressful situation, and a lot of lessons learned and knowledge gained!

Going through my past 3 years i can see clearly the main ideas that made this journey fruity at the end, i can sum up these ideas in the following points:

1. Don’t walk ever without a goal and a vision to achieve that goal.
2. Believe in your work, yourself, your vision, and in your colleagues.
3. Be Smart, Flexible, and Responsible.

Of course Agile is more than that, but i guess on the 2nd level of details, but on the 1st level of main ideas, i think this is what all about Agile!

Working as a team lead and Project Manager in Agile process gave me the chance to observe the whole situation from a higher view, a god view if you like. Also working in long running Agile projects showed me how the process evolve and how people become more familiar and adoptive to it everyday, it gave me the chance to experience and see all the lessons and practices I’ve been reading in Agile books, cause long running projects is a complete life with its ups and downs, failures and success, good persons and bad persons. and if you want you can observe all of that during the long running project.

The past week, i had successfully with my team delivered a 1½ year long project to the customer. summing up the good practices and lessons from this experience lead me to the following list:

1. Focus on People: They are the constructors in this industry; they are everything, they deserve all the attention! 
   • Share the vision with them clearly and honestly, people perform better when they understand.
   • Build the trust bridge between you and everyone in the team, speak with them individually, listen to their thoughts and complains, take actions when it’s necessary, and if it’s not possible; explain why!
   • People are more important than Processes and Tools! never pay more attention to a tool more than a person in your team.
   • Give them a space to perform, back off and let them finish the work, observe closely the progress but don’t let them feel it. The more the pressure increases in the project the more space you need to give them so they can finish!
   • Show them what goals they are hitting, share the goals achievement lists with them; take with them on group explain what were the goals and what we had achieved; speak with each member individually showing him the goals he needed to achieve, show him what he hit and what he miss!

   

   • Be Positive. People are very sensitive to negative emotions, be always positive with them, give them hope and inspiration.
   • Appraise them with any possible facility you got in hand, even if this facility is just some congratulation words.
   • Make a family of your team; get them close to each other. let them set together regularly, work in same location and space, hang out with them.
   • Understand their needs, to be able to motivate them.
   • Celebrate success with them.
2. Build a Team:
   • Think of a small group of members (5 to 8).
   • Hire the right team members; interview them yourself, test them yourself.
   • Use cross functional team; everyone is working everywhere in the project. 
   • Build the sense of responsibility inside them, learn them how to value their work and care about their final output.
   • Agile teams are self-organized; don’t just select someone in the team to be responsible after you about organizing people; instead teach them how to plan and think of priorities and then leave them to organize themselves.
   • Evaluate team as a unit; don’t just evaluate each member individually also evaluate the whole team as one unit including yourself and share the result with them and think with them where  are the problems and how you can fix it ?
3. Be Simple, Be Incremental: 
   • Start thinking about your system as advanced and huge as you can imagine.
   • Set clear defined goals for you project, and incrementally build it step by step.
   • At your first design focus on solving the project risks as simple as you can.
   • Put extensibility in mind but always remember that simplicity should be in the same equation!
   • Work Iteratively.
4. Simple Executable, and collective ownership Architecture:
   • Don’t build the system architecture by yourself; instead lead the building process; give everyone in the team the chance to share with his ideas in the design.
   • Build Executable Architecture, use small spikes/prototypes to sketch your ideas in code, don’t just sketch ideas on papers.
   • Break down the design into small pieces and allow each one in the team to work on a piece.
   • Use Simple tools (Whiteboards) for communicating your thought and ideas; architectural diagrams and models made for that purpose; teach your team to think and express in visual ways.
   • The more you hear this from your team member “I’ve design this ..”, the more confident you are on the right way cause you had build a collective ownership architecture.
   • Start with simple, exactable, and extensible architecture in project start, and accumulatively enhance and add new feature to your design all the way to project’s end!
5. Accept Changes All the Time:
   • Avoid defining all requirement at the start of the project! instead try to understand the available requirement.
   • Hunt as much assumption as you can at the start; move your goal from knowing everything to clear unknown points; remember that unresolved assumption become risks during the project constructions!

   

   • Build a clear simple product backlog at the start contains main project decisions and features.
   • Dive deeply in feature’s details at the start of the iteration containing the feature!
   • Accept the fact of changing requirement and priorities and work for it from the beginning!
   • Be honest and advise the customer, customers accept negotiation and sometimes don’t see the clear picture that’s why they ask for changes, be his technical eye and let him feel you are work for his benefit and please do.
6. Beautiful Code:
   • Select a standard way to write the code, the more people from the team involved in choosing this standards the more people comply to it.
   • Emphasize to people why we need to follow standards.
   • Teach them to use comments whenever it’s applicable to be guide on the rood for other colleagues.
   • Enhance and review your standards model as project goes.
   • Use Code Review meetings as a tool to share experiences between team members and enhance the project’s code.
   • Encourage Code Spikes, Pair Programming, TDD, and anyway the team feel it will increase its productivity as long as it will not affect any tradeoffs of the project.
7. Testing means Done:
   • Having a specialized role in your project for testing is not a bad idea, but making this role responsible for the whole testing process is a bad practice.
   • Everybody including you should be part of the testing process.
   • Testing a feature is required to mark it “Done”; that’s why developer must be involved in testing scenarios.
   • Testers are no less than developers; they are carrying 50% of the product manufacturing.
   • Teach developers how important Unit test for their code as an early safety net to discover issues before functional tests.
   • emphasize the concept of collective ownership for unit tests, anyone changes anywhere needs to makes the previous unit tests green and adds new green unit test for his modifications.
   • Use different types of tests depending on your project type; but any project should have at least 3 main type of test (a) Unit tests. (b) Functional Test. (c) Acceptance Tests.
   • Everybody in the project should be part of the testing cycle, from the customer (acceptance tests) to developers (unit tests); the more you can involve people in running tests on the project the better quality product you will have at the end.
   • Whenever it’s possible GO for Documented Tests.
8. Art of Documentation:
   • Fact: No one love writing documents; and no one reads them, but yet there are a very slick slice of docs are important.
   • Don’t make people fill documents that are not important or you know it will not be useful.
   • Show people why this document are useful before they writes it; learn people how to use the project documents instead of asking each others; remind them whenever they use some docs they had wrote before how this docs was helpful for them now.
   • Use visual documents, diagrams, flowcharts, charts, and images.
   • Minimize documentation to the absolute necessary.
   • Everyone owns any document; we are working together, anyone allowed to update in any document as long as there are a good reason and we keep history of the changes.
9. Smart Process:
   • If you don’t have a process to start with, build a simple one that fits the current environment and people then start enhancing it as projects moves.
   • If you do have a process examine if it fits the current environment and people; make necessary changes then start immediately.
   • Don’t copy processes and rules from books; be smart read what others do and select, develop what you can use of their practices in your current project.
   • Discuss your process with the team; there are always a room for improvement.
   • enhance one practice or activity each phase; don’t make major changes, people hate major changes they don’t believe it will do anything and they take time to adopt to it.
   • Keep your process stable for some time, people need to be comfortable and adoptive with the process before they can share with ideas and enhancements!
   • Forget about Tools, focus about practices.
   • Processes are not written on stones, do changes whenever you feel you need it; be flexible when situations require that.
   • Make your process clear and understandable for everyone in the team; don’t hide anything or use any secret roots in the process.
10. A Manager for A Project:
    • Be transparent, honest, direct, and positive.
    • Teach people that management is part of the project roles it’s not a higher level or position.
    • Know that “you can Delegate Tasks, but you can’t Delegate Responsibility”; you are always responsible even if it’s not your fault.
    • Responsibility is share between everyone in the team, if one failed we all failed!
    • Smash the manager’s door red lamp; work closely with your team, set next to them, be transparent about your work with them, whenever it’s possible share information about your tasks and work with them, don’t just say i’m busy when you are needed, explain why you are busy.
    • Lead people, Manage Project.
    • Listen to the team, listen to everyone thoughts and complains, build trust between you and people work with you, make them comfortable talking about problems and criticizing anything they want including you!
    • Delegate some of your tasks to team whenever it’s possible, so they can see and feel what kind of work you are working in.

Of course there are more about Agile. I tried to collect the best practices from my last experience in this long project, i though it might be helpful. For myself as i’m turning this page of the past 3 years of my career and looking forward for the new phase of my Agile Career Life, sometimes i think to myself this is my Agile+

Hope this Helps,
Ahmed