Improve Productivity and Collaboration with Agile
Agile is a robust method that can benefit software development teams. Agile makes the team go faster and lets the team see how screwed they are in time to make a difference. Yet, it can also be challenging to put in place.
Processes are not free. It will affect productivity and morale — often. The lightest, leanest process you can get away with is always best — and you will be amazed how little process you need. Programmers are self-managing and self-motivated. Resist the desire to track everything. Programmers thrive in a flat organizational structure. Allow each programmer to track their tasks with whatever tool they prefer.
Refrain from relying too on long-term road-maps, as they are likely to change. Pick a release cadence, like once a month, and ship whatever you have. Pick a set of features and ship whenever it is finished. Market what you have, not what you will have. Do not force programmers to commit to completing certain features by the end of a sprint or a specific date. Estimates should be as accurate as possible but only as precise as necessary to keep the estimation cost low.
There will always be bugs in your software. There will always be tweaks to be made to your user experience. There will always be code that needs to be cleaned up. There will always be more tests to be written. And there will always be more documentation to write. Because there is always more work to be completed, you will have to make a judgment call about when to stop. Thus, “done” is a decision, not a definition. Do not attempt to collect metrics or enforce standards to automate this decision. Trust the intuition of your programmers in this matter.
Programmers work remotely or have private offices or both. Collaboration should be asynchronous and online whenever possible — allowing remote efforts to be on equal footing with on-premise work and giving permanent records to items discussed. Have everyone do meetings online, even if many programmers work in the same office. Use video/voice tools (Hangouts, Skype, FaceTime).
A sculptor has a process of his own. He may have sketched his projects first and built a completed version out of plaster before even starting with the final material. It is best to leave him alone to carry out his work. Imposing an exterior model on his efforts would only result in frustration, poor quality, and delay. Like designers and artists, programmers can and should be trusted to make correct product decisions.
The software industry still needs to work on enjoying true Agility. A practical approach to Agile follows a transparent, open environment to avoid micro-management. The fear of uncertainty forces people to create processes and limit responsibilities. Separate teams should use their extra time to uncover opportunities and create value for the business.
Failure is uncertain and scary, yet, when teams do everything to prevent losses, they also reduce innovation. Practical Agile or Agility is a mental shift toward producing value beyond feature development. More features mean nothing if you’re flying blind. Before getting busy writing code, you need evidence that it’s the right thing to do. Search for opportunities to make it simple instead of adding more complexity to your work. Simplicity over complexity. Sprint by Sprint; the team strives to provide value to end-users.
Agility places a structure around the learning process, enabling teams to assess what they’ve created and how they made it. Making people focus on value forces them to produce that 20 percent first. When they’re done, they realize they don’t need the other 80 percent or that what seemed important at the outset isn’t. What Agile does is bring teams together to create great things, requiring everyone to see the end goal and to deliver toward that goal. More features mean nothing if you’re flying blind. Before getting busy writing code, you need evidence that it’s the right thing to do.
A company that isn’t making money is not a business but a hobby. One of Agility’s virtues is that it makes the uncomfortable visible. If something is half done at the end of the Iteration, you’re better off than if you still needed to start. You’ve expended resources, effort, and time and have yet to get anything to a deliverable state. A team that depends on regular heroic actions to meet its deadlines is not working as it should.
Agility implies collaboration. Software development is unpredictable, and investing too much time upfront on a plan will generate waste. The time to market is extensive, and end-user learning takes too long. Instead of improving collaboration and benefiting from Agility, teams fall back to a waterfall working mode. Agility is all about empiricism and partnership. It will only work well once teams can embrace uncertainty and are empowered.
Collaboration over contract negotiation. Instead of having to change deadlines is better to collaborate often with the stakeholders of the system that the team supports. Sometimes we have to if we’re combative, but most times, in a good business environment, we are going in good faith and collaborating.
Good collaboration removes some of the blocks people have to do their jobs but only sometimes makes them more skilled. There needs to be detailed reporting to management. Anyone in management or on another team can walk by and look at the avionics Scrum board and know exactly where everything stands. The greater the communication saturation — the more everyone knows everything — the faster the team.
Open source projects are released at early stages when software is incomplete and buggy. Those interested in this software are tolerant of the instability and often collaborate on its improvement. As a result, open-source software is improved. This can lead to faster problem-solving and more efficient use of resources. This can also lead to more autonomy and ownership among team members, increasing motivation and buy-in for the project.
Team members are empowered to negotiate between them. Projects are planned, developed, and maintained by the entire team, not individuals. Team members have direct access to those who need the solution. There’s no such thing as a team if there’s no identified customer.
A group where every member has the skills, confidence, and empowerment to take the initiative, make decisions, and lead others. When people see problems, they think, let me take the lead in solving this issue.
Communicate project status to stakeholders. Manage and call out risks. Team members should ensure the quality and reliability of shipped products. Help the team ship and delegate (both to the team and upwards). Motivate the team on the way. Set up a framework for collaboration. Break down the project into milestones & provide estimates on these. There should not be a global entity managing the work of the team members. Individual team members are not a good metric to assess the complexity of work. Another approach is to trust and empower the team members by giving them autonomy to make decisions and solve problems.
On the one hand, taking risks and being mindful of the hierarchy within the organization is essential. It is about setting clear expectations, providing support, and fostering trust and empowerment. It’s also critical for managers to be mindful of their management style and be open to feedback from their team members. Walking can be challenging, but this inner conflict drives the manager to be a more effective leader and advocate for their team.
Managers build the product rather than empower others to make things faster and better. Team members should help each other to identify and solve problems. This approach fosters autonomy and independence, leading to successful and fulfilling outcomes.
Teams should review their agile methods, identify areas for improvement and make changes as necessary. This helps ensure the team stays aligned with the agile principles and continues using the most effective practices. Agile methodologies rely on collaboration and communication to be successful. Teams should foster a culture of open communication and encourage team members to share their thoughts and ideas.
Agile teams should always keep the focus on delivering value to the customer. This helps ensure that the team stays aligned with the project’s goals and that they are not getting bogged down in unnecessary details. Agile methodologies are designed to be flexible and adaptable. Teams should be prepared to make changes as needed to ensure that they are meeting the needs of the project and the customer. What cripples communication saturation is specialization — the number of roles and titles in a group. If people have a particular title, they tend to do only things that seem a match for that title. And to protect the power of that role, they tend to hold on to specific knowledge.
Teams should define clear and measurable goals for the project at the beginning and use them as a guide to determine when the project is complete.
—
