Archive for the ‘Uncategorized’ Category

The power of feedback loops

Posted: June 14, 2015 in Uncategorized

Nice breakdown of the importance and often forgotten areas and types of feedback loops within software development.

Luca Mezzalira

Working in software development requires that we find the right techniques to achieve quality and customer satisfaction. Learning about development and flow techniques from experienced peers can be helpful. But if the team has a lack of senior peers or insufficient commitment, we may have to find alternative routes.

While studying how to improve my methods, I watched an interesting video wherein Noel Ford explained how useful feedback loops are in software development. Working from that premise, I started collecting and applying the best practices that could most help developers deliver software that meets customer expectations while also improving code quality.

First of all, let’s define a feedback loop. According to Wikipedia, “Feedback occurs when outputs of a system are ‘fed back’ as inputs as part of a chain of cause and effect that forms a circuit or loop.”

Any Agile or Lean framework incorporates this concept, but I…

View original post 1,120 more words

Scrum Master

Planning and estimating tasks in Scrum involves creation of User Stories, approval and estimation of User Stories, creation and estimation of tasks, and creation of Sprint Backlog. Creation of User Stories involves writing of User Stories and their related User Story Acceptance Criteria. User Stories are usually written by the Product Owner and are designed to ensure that the customer’s requirements are clearly depicted and can be fully understood by all stakeholders. The Product Owner, based on his or her interaction with the stakeholders, business knowledge and expertise, and inputs from the team, develops User Stories that will form the initial Prioritized Product Backlog for the project. The Prioritized Product Backlog represents the total sum of what must be completed for the project. The objective of this exercise is to create elaborated and refined User Stories that can be approved, estimated, and committed to by the Scrum Team. At…

View original post 592 more words

Good overview and analysis of Lollipop 5.0

Agile Net'Up

View original post

Some really useful observations made here, logical but often overlooked!

Technical Software Testing

It’s fairly safe to say that quite a lot of test automation efforts fail. It is also very safe to say that without test automation an agile team fails. So how can you make sure that while doing agile your test automation will not fail and thus your agile team will not fail? One of the ways to answer this question is by looking at why test automation often fails within agile environments.

When I am talking about test automation within this post, I am referring to testing that is done to reduce the amount of manual regression work, the so called functional test automation or automatic regression testing.

Moving target

Test automation quite often does not receive the attention it needs and deserves, also in agile teams. Quite some test automation efforts start off too late and without the appropriate preparation, resulting in organic test automation driven by a…

View original post 838 more words

Wherever you go, whatever blog post you read, whatever company you do business with; there is likely to be a general journey theme when it comes to implementing agile; especially the transition from positivity through to surrender. “We are doing agile”; “my velocity is bigger than yours”, “I can’t believe our release is delayed because our downstream system isn’t agile”, “this agile thing sucks, it just doesn’t work, and now they want to use offshore”, “great, so now we death March every second week”, “my technical debt list is bigger than my backlog”.

Ok, so the last one I added a bit of poetic license to, but I think the point holds, at the outset of the bright new world, positive vibes and optimism are plentiful, as problems arise, if they are not dealt with, they escalate and confidence turns to confusion which leads to defeatism. This attitude isn’t an agile problem, it’s a standard project problem, if ‘risks and issues’ arise on a project they are managed or mitigated; in agile, the same holds true. For the purpose of this post, I’ll concentrate mainly on Scrum approaches

Let’s look at the statements outlined:

We are doing agile“are you sure? Asking the same three questions each morning, doesn’t mean you are “doing” Scrum (agile). How are you finding the journey, do all of your team members and sponsors understand the investment required in time and people to find the benefits of applying agile principles? Do they understand the role that each needs to play, especially during sprint planning and retrospectives?

“my velocity is bigger than yours” – great! So how are you using a backward looking measure to assist your future release train? How are you applying what you have learnt to road mapping the next set of features in the backlog?

I can’t believe our release is delayed because our downstream system isn’t agile” – is it really the downstream systems fault? Turn the situation round and ask “as a scrum team, why didn’t we understand our dependencies? Why didn’t we have an acceptance test that covered this integration? ” as a self organising team, each story that goes into a sprint needs to add business value, needs to have a clear objective (I.e the scrum team will agree what the expected sprint outcome is for a story, such that it will either demonstrate UI layout via the use of stubs or that it will be partly or fully integrated), needs to be technically feasible, has to be testable and needs to understand its dependencies. Having a project roadmap (the “Release Train”) will help visualise the technical priority, aligning development to fit with downstream or third party systems will keep the train moving, and allow stakeholders to apply pressure where necessary on suppliers to meet the demands of the train.

this agile thing sucks, it just doesn’t work, and now they want to use offshore” – again, does the scrum team and the stakeholders and sponsors understand the commitment required? What problems are being faced? Are the retrospectives being used effectively, to identify common problems in the approach, that can be tackled by the team to improve the collaboration and quality of the team? If these are addressed, what is the next area that “sucks”, continuous, manageable improvement builds confidence over widespread overhaul. In terms of offshore, what elements are being offshored? If it’s development, are the offshore team working in-sprint or are they feature based, complimenting the onshore development team; perhaps running a more Kanban; just in time approach, limiting the amount of work in progress to demonstrate progress? What about testers offshore? If we think about the obvious benefit and alignment to agile / scrum principles in terms of constant early feedback; utilising offshore resources means that developers create the nightly build, the offshore team test and feedback is available first thing when the developers arrive, they can fix and build and the onshore testers can retest and close the cycle down. Maybe the offshore team are focused on regression capability via automation, taking pressure off of the onshore team to focus on acceptance and collaboration? In short there are many ways to improve the approach, and find the approach that provides the benefits that the stakeholders envisaged when they decided to adopt agile.

great, so now we death March every second week” – if this is the case, we need to back to the sprint planning; what did we do wrong? Did we understand the complexity and dependencies? Was the product owner available to give us the insight; were the UX designs ready? What did we forget? For scrum to succeed, we need to manage the backlog and during the sprint not over burden through either underestimating or taking on too many stories; doing so will add to the technical debt either through “hacks” to get the function working or outstanding defects that cannot be fixed in sprint.

my technical debt list is bigger than my backlog” – following on from the last point, why are we building technical debt? How can we change? Is the technical debt related to new versions of development tools or architecture? Do we need to refactor the code to migrate new tools in order to achieve new business goals? If yes, then do we assign a technical sprint to refactor in order to kick on?

Only the team can decide ….. Well the team and the now fully educated stakeholders!