Logbook, Notes, Thoughts
Did you ever had the feeling, your team could be better? Have a higher performance? Be able to produce better outcomes?
I'm not talking about successfully finished sprints versus failed sprints or the constant struggle to increase velocity.
I mean your product - that thing your team is building. May it be your company's product or a contract work for another company.
Continue reading "Why your Scrum Team is not performing as it could"Recently I had quite some issues with sending data via POST to a webservice from an Android app.
Continue reading "Issues to POST streamed data to a webservice"The dependency injection library Dagger by Square setup for using it with Eclipse is a bit different when not using Maven.
This post is part of a series: Becoming Agile.
Usually we have certain constrains on our project which define what we can achieve and most likely also what we have to do first. Having a backlog packed with user stories makes it very difficult to get an overview of the upcoming workload. To be able to actually get an idea for the upcoming sprints we need to estimate the product backlog. Doing that detailed for each user story would take us quite some time. So instead of estimating each single user story (as exact as possible) we could try to estimate a bunch of similar user stories at once. This is Magic Estimation.
Continue reading "Becoming Agile: Magic Estimation"This post is part of a series: Becoming Agile.
As soon as new code is finished it should be integrated into the code base. By that it is not only ensured that all members of the development team get access to new code, it also minimises the risk of running into incompatibilities and reduces the complexity of merging changes.
In a recurring fashion this could happen at the end of development day. Also partly finished features can already be pushed into the base as long as they meet the project's quality minimums (etc. testable/tested, documented). At the beginning of the next development day changes would get individually pulled into the working copy.
Testing code is a crucial part in reaching a certain level of quality and stability. To minimise the workload needed the process should be automated where possible. This can be done with unit tests using state of the art testing frameworks (JUnit, Selenium, etc) to further reduce workload.
It should be also possible to combine testing with continuous integration. This gives the advantage of running tests as often as possible and getting the chance to react to issues quickly.
Each team member should keep the future constantly in mind. As the application grows requirements might (or most likely "will") change. To be able to react and implement these changes it is important to always develop for scalability and flexibility. This accounts not only for the development members but also for the management members of team. The management should always evaluate new features with what might come next.
Always create the simplest solution for a problem that will work and deliver for the minimum requirement. Maintaining a simple, clean and open design ensures that the application can be easily extended while staying focused and meeting dead lines.
