What is the perfect office environment for agile development?

The first of the April Practical Agile Meetup’s  conversations was about the best environment for agile development.

Disney Castle

When you develop upon a star…

And the first thoughts were “It Depends”.  Different stages of the development have different needs. Discovery needs a space for discussion, Development needs somewhere to sit.  A fixed space is bad and teams ideally should be able to determine their own layout (taking into consideration Health and Safety requirements).

The Disney Brainstorming Method was brought up. This is a process for creating and refining new ideas using Dreamer, Realist and Spoiler point of view.  The idea is using 3 separate rooms where only the Dreamer POV is allowed in the first, only Realist POV is the second and only Spoiler POV in the third. The idea behind this is many ideas can be examined and refined without stifling initial creativity.

Whiteboards proved a great source for discussion, with many teams using them to partition off their workspaces in open plan offices in addition to their more traditional role as scrum boards and idea capture.

It was felt that all too often that everything gets written down and they can quickly become noisy and out of date. We’ve all encountered the lonely whiteboard in a deserted room with “please do not clean” scrawled on it. If it’s important why not take a photo and then it can be filed and shared as needed and the board is ready to be used again?

The group discussed the virtues of Physical vs Virtual  Scrum boards. Many teams used both which led to the question of which one showed the reality? The majority opinion was it would be the electronic version but that it needs to be used properly with team members burning down estimates and making sure tasks and stories were updated in a timely manner.

The duplication of information has a potential of causing confusion and in some cases the Scrum Master updated the physical board to make sure it reflects the virtual board.

Many teams have large monitors to display the team metric. One point of view was that this can be seen as a pure PR exercise to show internal and external customers that this is a high tech hub activity. However real time data can be very useful to the team where it is appropriate and desired – for example build health.

The need for a public display of information was felt to be an important part of the Transparency needed for Agile by making easily visible the progress and status of work to the team, stakeholders and other teams. Again this brings up the need to identify what is needed and useful to communicate to the wider audience as well as the team.

One common issue always seems to be noise level; My team has a healthy buzz, Your team is making a racket. Communication is central to agile. Tolerance and Respect for each other would seem to be the solution, with team members feeling comfortable enough to call out when there are issues.

As an offshoot from the main topic under discussion, an interesting method of dealing with tardy team members ( a general sore point for everyone) was suggested. At every meeting an individual is late for a mark is tallied against their name.  At the end of the week/sprint the team member with the most tardy marks buys the treats.

Clock Cake

There’s always time for cake!

Advertisements

Are All Disciplines Equal?

This discussion was around the differing perceptions of the specialist roles within a scrum team and how the relationships can be maintained or made better.  The main points are listed here, but please feel free to add any more in the comments.

  • An observation was made that if a comment or suggestions is made by a tester it isn’t given any consideration, however if the same suggestion is made by a developer then it is immediately accepted and usually acted upon.  All opinions are equal and should be treated as such, regardless of the persons job role.
  • The ideal make up of a scrum team would be to have multi-talented T-shaped people, which would still value the specialist skills of each discipline but would give more flexibility to complete any task.
  • Job descriptions can reinforce the perception that a developers contribution is more valuable by using phrases such as helping the developer rather than concentrating on the testers skills.
  • Job titles can also influence this.  One example was that everyone within a project should be called an engineer, it was thought this would naturally lead to a more inclusive approach.
  • One scenario discussed was the testers being allocated to a project from a central pool of testers, rather than integral members of the scrum team.  This led to the test resource being removed or reallocated.  In order to counter this, the the testers were involved throughout the life of the PBI from requirement gathering, to pairing with the developer, making it more difficult to remove the test resource from the team.  While this works around the problem, it is no substitute for a fully integrated team.
  • Automation could be used as a bridge between development and testers, giving each an appreciation of the other’s skills.
  • Giving the testers the skills and authority to correct minor bug themselves was also discussed as a way to gain appreciation and respect.
  • Some people were discussed as being role models and encouraging the relationship between the two disciplines by getting involved with tasks outside of their traditional role, helping with automation and training their colleagues.
  • We also discussed that often any issues within a team come down to personalities rather than any lack of respect for the job role.

 

 

Practical Agile Is Born!

On Tuesday the 5th April 2016, we held our first session of Practical Agile. Agile professionals from prominent North East employers, including  hosts NCFE, Sage, HMRC, DWP, Orchid Software and Coatsink Software, met to discuss their experiences and challenges.

The night started with an overview of the aims of the group, which is to create a community to share knowledge and support each other in real-world agile challenges.  This was followed by a brief 5 minute run through of NCFE, their current approach to software delivery and the challenges faced.

20160405_181740

 

Following this, we broke into two groups and the conversation began.  The first topics up for discussion were decided based on feedback from those who had registered to come along.  These centered around the relationships between the multiple specialist disciplines within scrum teams, and getting the balance between agile practices and more traditional project management expectations.  You can read more about the key discussion points here and here.

The evening was well received, and we are looking forward to the next session in a months time where another company will share a brief overview of their team and the topics for discussion will be decided by a vote on the day.  If you have feedback from the event or suggestions for future topics, we would appreciate it so please add a comment below.  We’d love to see you there, if you would like to join us please register here.