How can agile be used as the foundation for a successful business?
This week I have been looking at agile practices in a more practical sense, it has been interesting to see how companies use agile as a foundation for developing products. While looking at agile, I have been considering how I could use agile practices to improve my own work and apply them to my own business. The main areas I have been looking at are planning, estimating, and envisioning. I also took a look at using sprints to improve existing products.
My preference and why:
I really like agile practices, they allow for a team to provide a dynamic product that can adapt to any changes in requirements while also allowing constant improvement. Agile practices also provide individual developers
with better ownership over their own tasks, and I firmly believe that an expert hired for a task will perform better when allowed to do their job free of micro-management.
Feelings:
I have appreciated that the research this week has a lot of directly practical use. I strongly believe that agile practices can be the foundation and core of a successful business in software. The things I have learned this
week should form the basis of how my own business should work I have found estimating a hard part of using agile development, so when I learnt about the bucket technique, I thought that it was perfect for me. I
also usually have a problem with estimating everything to an ideal day and learning what an ideal day means has made a big difference to how I see my work.
Another thing I liked was the idea of team velocity. If I always plan out tasks for a perfect day then I will be working extra to ensure I hit deadlines. But by calculating my velocity, I can work out how efficient I am working each week and adapt my estimations so that they are more accurate without having to perform longer work to keep up.
Finally, user stories are a great way to help developers understand the purpose of a task, allowing them to solve their problem by understanding it instead of just doing as instructed. Because of this, user stories are a good tool to allow the developer to be independent while working.
At the GPC, we have used user stories for only a year or so now and I find it really helps us focus on the issues a user may face and build better systems.
A quick analysis and evaluation of Agile Practices:
Both the games and software industry have nearly fully adapted to agile workflows, in fact, Christof Ebert and Maria Paasivaara suggest that “The rising demands for high quality, quick delivery, reduced costs, and
flexibility have pushed agility to practically all industries” (Ebert and Paasivaara, 2017).
However, I don’t think that a lot of newer businesses fully understand some of the finer points such as estimation and planning within agile. A lot of businesses I have worked with understand agile to be working
in sprints and nothing more. While this is a core part of agile, it only scratches the surface/ the techniques. Pitching improves when you can give accurate answers to time estimates and user stories help sell the idea to both the funding provider and the rest of the team.
Because of the uncertainty around agile development, investors are not likely to prefer it over traditional development. Instead of making a well-defined product within an agreed timescale, which is safer, agile development constantly reassesses its position to improve the product at the cost of accurate timescales. This creates risk for an investor, so knowing ways to mitigate that risk will encourage successful pitching.
Playing on the advantages of agile; being able to adapt to market changes, creating a product that is better suited to the end-user, and an ability to implement feedback, will improve chances at funding. While being able to better explain the idea of a product will help get an investor on board with an understanding of why, and not just what, you are trying to create.
When the whole business structure is based around an agile workflow, the business can easily offer dynamic products as a service, creating new ways to develop and sell products that update post-launch with improvements, new features, and fixes. While this can happen without agile, it can be much harder to deliver as any work past the delivery would not be budgeted for.
Christof Ebert and Maria Paasivaara recommend that agile teams should cover different disciplines. Specifically, they recommend to “Move from classic functional responsibilities to small, cross-functional teams. Grow methodologies and the underlying technologies to agile engineering”(Ebert and Paasivaara, 2017). I believe they recommend this for two reasons, firstly because a multi-skilled team can cover a small amount of every area of traditional development.
The short sprints require deliverables and having a variety of skills to handle a wider range of tasks will help bring a more complete product to be reviewed at the sprint. Secondly, having experts in different areas allows each expert to do the tasks they are good at, and having a variety of experts in different areas means each area of the product was made by someone experienced. Of course, developing with growth in mind is important too. Having a multi-skilled team will allow the team’s members to learn from each other, something many developers want from their careers.
Self-Crit
What I did
This is a hard week to find a task for. The challenge task I performed was to create a user story for one of my rapid ideation tasks. I am also on holiday this week so I cannot discuss changes to our workflows with my work team until I get back.
So instead, I experimented with some of the new agile practices I have learned in a simulated version of our team on a game called software inc. (which I recommend as the best software company simulator on
the market)
What went wrong
I already had a good idea of who my target audience was on my rapid ideation task so did not have any issues with this task. My experimentation in the simulation hit issues as I scaled from small to large teams. In order to scale up, a large amount of management was required. In fact, ensuring the teams had the right people was one of the most important aspects of working successfully. Team construction was important enough to be the main focus of my time experimenting. It will be interesting to try this out in real life.
How can I overcame what went wrong
With agile, the team is at the core of everything, but even on my own, I can use some of the agile techniques. I really liked the estimation techniques, and user stories are helpful for explaining not only what we are making but also why.
What went well
I enjoyed creating the user story for my RI project. When I first created it, I was thinking about myself, but looking back at a potential target made me think more about their life and how my app fits into it. I will be using user stories in future projects as I can see them being very useful.
What I achieved
I now have a bit of, albeit digital, experience in some of the agile practices that I had not heard about before. I will be proposing we adopt the majority of them as I found them incredibly practical.
What can I improve and how
I am quite interested in the agile movement, I am hoping to attend some events to learn more later in the year. I am also interested to see how some of the studios I know use agile in ways I do not yet know, I will be asking around and researching further to see if there’s anything I can learn.
Action Plan
- Propose new agile practices to be adopted with my team when we meet up next
- Investigate agile events such as Agile on the Beach.
- Ask other developer I know about agile practices I may not know about when I next see them
- Research further agile practices I do not yet know at the weekend
Conclusion
So, Agile is a practice that allows more flexible product development, but this week I learned about how to apply it more practically, something I greatly enjoyed. I covered ways to estimate, ways to envision a product, and even tried out the practices in a simulated environment. I think this will be very useful in both development and I am hoping to apply the same methodologies to my pitching in the future. I think being able to explain: what the product is, why we will make a product, and how we will successfully work on a product, along with accurate estimations will show an investor that we know what we are doing and are a lower risk. This week has been practical and useful.
Bibliography
Ebert, C. and Paasivaara, M., 2017. Scaling Agile. IEEE Software, 34(6), pp.98-103