Stream

Pinned by moderator

Agile+
owner

Read Here First  - 
 
STOP! Don't post yet! Read the "About this community" box to learn the rules for posting in this community. If you don't follow the rules, your post will likely be removed without warning. More instructions --> https://docs.google.com/document/d/1qWhX4BVjD1O3ROTRs2U53kyJeSaCnTQrqqYrJA4qyjg/edit?usp=sharing
8
1
Jana Olsen's profile photoAlan Dayley's profile photo
9 comments
 
I updated the document to include a screenshot of the new web interface and updated the iOS screenshot image.
Add a comment...
 
Funding an Agile project is not rocket science
If you treat people like people and fund projects in a more sane fashion then you are likely be more successful at Agile. This week I blog about financing and agile project management.
Software professionals are not Lego bricks. I had the good fortune to finish a training course by Benjamin Day about scrum master skills. I highly recommend you visit Pluralsight and take his course. One of the more interes...
3
Edward Wisniowski's profile photoSteve Sether's profile photo
7 comments
 
+Edward Wisniowski The way I recently heard the lego-brick metaphor was picking out different pieces of a custom built ERP system and incorporating them into a new system.

The problem being, that the ERP system wasn't designed as a series of discreet components with clean interfaces between them, but an integrated system with complex interaction between components that evolved over time and over an expanding business.

The lego brick mental-model (as it was described to me 3rd hand) leads the business users to think of the system as components that can be easily broken apart, like lego bricks.

For a lot of people, it's tempting to think software is like this. Just standard, pluggable things that don't require much integration.
Add a comment...

David Koontz

Discussion  - 
 
Team Metrics a case study. http://agilecomplexificationinverter.blogspot.com/2016/06/team-metrics-case-study.html

Please comment - what do you find interesting in this data?
Let's look at an info-graphic of a beginning team's metrics and use this as a case study in Scrum Team Metrics. Description of charts: Burndown chart - a daily count of the number of task units (aspirin is this teams sele...
2
David Koontz's profile photo
6 comments
 
getting some great insights in the comments on the blog site... check them out and add to the dialogue - that's the purpose of a case study
Add a comment...
 
I feel mighty strongly about this
A scrum master is not a Jira jockey or updating the scrum board or scheduling meetings. He or She is so much more and we need to start acting accordingly. 
A good scrum master is like a good camp counselor As we head into summer, it is a good time to reflect on the first half of the year. I am going through numerous personal and professional changes. My role is going to be cha...
6
Steve Sether's profile photoEdward Wisniowski's profile photo
3 comments
 
It was a long time coming +Steve Sether so I was not concerned. I appreciate that I am being treated as an agent of change in my organization.
Add a comment...
 
Some thoughts about process
I received a lecture from a manager about process and why it is a good thing. I restrained my gag reflex and urge to argue with them and instead wrote this blog article. 
Responding to change is like jazz, blues, and rock One of the central tenants of the agile manifesto is responding to change over following a plan. For someone with a background in science or engineering it seems commonsense...
2
1
Rod Dunne's profile photo
 
and not to forget - Individuals&Interactions over PROCESS and tools :)

Add a comment...

Veit Schiele

Discussion  - 
 
Interesting article on SOA, Microservices and Agile.
The rise and fall of SOA can teach us much about making the best use of microservices
1
Steve Sether's profile photo
 
SOA is a buzzword that's been abused.  About a year ago I worked on a project that was supposed to have a SOA interface...  but the only "service" it provided was essentially file transfer.  It could have been replaced with FTP, and no functionality would have been lost.

The problem is that people take on new words, but don't take on the underlying concept.  They try to adapt the old concept onto the new one.  This is what happens much of the time with Agile.  Take the old Waterfall methods and mentality, and "bolt on" some agile. 

There's just not enough understanding of humans, and human behaviour in technology.  We talk a lot about technologies, standards, etc, but we don't talk enough about people, conceptual revolutions, big ideas, philosophy, mental models, and how people actually behave rather than how we want them to.

More often than not, we're just talking past one another.
Add a comment...

David Koontz

Discussion  - 
 
RE: Jean Tabaka - from Yves Hanoulle

I guess by now most of you have already heard that Jean Tabaka passed away.

This morning in the shower, I though that the best way to honor Jean, is by collaborating together.
Collaborate and share stories.

The document below is a google slideshare document that anyone can edit.

https://goo.gl/6c17mO
I added a few slides that are my ideas on how to do that. if you have a better idea, just change the slide.

Feel free to forward this mail or these slides to anyone you think might want to join in.


Yves
1
Peter Bormann (Valonqua)'s profile photo
 
That´s very sad news. RIP! 
Add a comment...

Holger Schauer

Discussion  - 
 
I wonder what are your experiences whether it makes more sense to strictly follow the movements (e.g. Scrum rituals) first or whether to take a more loose approach when introducing agile? After all, we're dealing with intelligent people. I know, the consultant answer "it depends" surely applies ...

(Btw, the article below was linked from https://www.infoq.com/articles/agile-jedi-scrum which discusses a related point, that you can do Scrum without being agile).
2
1
Steve Sether's profile photoDaniel Markham's profile photo
6 comments
 
I'm with +Mike Bowler on this. Bring in an expert.

One of the problems is that it's far too easy to confuse the work and the structure of stuff we do around the work.

For instance, people do the demo and expect the PO to approve of the work at the demo. But why? If the PO is working alongside you, they should be approving the work as you go along. The demo is for external stakeholders.

Same goes for stuff like Sprint Planning. Everybody shows up to plan for the sprint and suddenly there's this huge hubbub of design and analysis going on. Are you not talking during the week? Are you not working together daily? If so, you should very quickly come to terms on your overall vision, strategy for execution, how to resolve conflicts, and so forth.

I blame a lot of this on people just not working side-by-side. They show up in a conference room every now and then for some kind of "Agile Meeting" that's on the calendars and then all the stuff they should have been working out as they went along pops to the surface and it's too much to deal with at one time.
Add a comment...

Daniel Markham

Discussion  - 
 
This seems to be the wave of the future.

Companies and folks seem to insist on taking people and putting them into specialty roles, as much as we talk against it. In fact, the number of buzzwords and roles keeps growing every year.

If that's the way it's going to be, looks like the only answer is the entire team doing single piece flow, aka mob programming.

http://underthehood.meltwater.com/blog/2016/06/01/mob-programming/
June 01, 2016 Posted by Karin Obermüller and Jeff Campbell | Comments Mob Programming - the Go...
4
Steve Sether's profile photoDaniel Markham's profile photo
2 comments
 
Yes. I think the unspoken bit here is "be prepared to work through problems you may have swept under the rug until now."
Add a comment...

Franco Martinig

Discussion  - 
 
An interesting article that propose an alternative viewpoint to the traditional project (management) approach for software development.
#NoProjects discusses the inadequacy of projects for software development, especially with Agile approaches.
9
1
Add a comment...

Created by

About this community

READ THIS PLEASE! Posts that do not follow these rules may be removed without warning. - Agile+ is NOT some new Agile framework. We are a community interested in all things related to Agile ideas as defined by the Agile Manifesto. - When you post links, include some text as to why you find the particular link interesting to Agile ideas. - If your post is flagged by Google+ as possible spam AND your profile contains only similar broadcasting, you may be banned as a spammer. Yes, we check your profile. - If you are posting under an entity name (company, organization, etc.) you MUST "plus" your personal self as the author. "Individuals and interactions" please! - No sales pitches. Announce a conference, don't sell it. - No job postings. - Agile+ Team: James O'Sullivan, Miguel Rodriguez, Mike Bowler, Alan Dayley and Geoffrey Dunn

Daniel Markham

Discussion  - 
 
Coaching Fun

Had a great intro course over the last couple days with some folks. Today we sat down and started Sprint 1.

As part of Sprint Planning, we fired up the linux VM, started installing and running some cucumber. Somebody goes, 'Oh, are we really starting now?"

Yes. We are really starting now.
4
Daniel Markham's profile photoDavid Koontz's profile photo
3 comments
 
I prefer to answer that query as - no, we already started some time ago...

By the time many people think something related to change has started - the people instigating the change have already thought and planned and sceamed about it for a long time... most "starts" happen before we are aware of them.
Add a comment...

Alan Dayley
moderator

Discussion  - 
 
*Question:*​ How do you teach a team to work in a collaborative way?

​*Context:*​ As a coach I often spout the word ​_collaboration_​ at teams. “You should work collaboratively.” “Just collaborate on the problem.” Great. If the team has never worked in a collaborative way and the culture is one of following orders, they don’t know how to collaborate. They might think I’m asking them to send more emails to each other or put more documents on SharePoint. It is not helpful for me to tell them to do something but not show them how to do it.

​*Goal:*​ Spend one hour with the team. By the end of the hour they will have learned the difference between collaboration and other ways of working like cooperation and coordination. And by the end of the hour they will have ​_experienced_​ collaboration in some small way.

What are some ways you might meet this goal? What are some resources you would use or exercises that would work? I have some ideas, yours might be better.

My ideas start from here: http://www.solutionsiq.com/achieve-true-collaboration/
Find out what true collaboration really means and how agile practices help create an environment where collaboration is truly possible.
3
Holger Schauer's profile photo
 
Eben Halford makes an interesting point in his team presentation (https://www.infoq.com/presentations/team-groups-culture): if you want a team to collaborate, give it team-size tasks, don't chop it down into small bits that individuals can handle. The bigger size encourages the team members to collaborate to be able to tackle the task.
Add a comment...

Alan Dayley
moderator

Discussion  - 
 
Synchronized Iterations: Why?

The Scaled Agile Framework (SAFe) codifies the advice of many Agile practitioners: When multiple Agile Teams work closely together, synchronize the start and end of the iterations or Sprints. As a coach, I struggle with this advice because of the problems it causes for stakeholder attendance of demos and for cross-team interaction.

- I can't attend your Sprint Planning because my team's Sprint Planning is at the same time.
- She can't attend our demo because your demo is at the same time.
- Teams tend to ship (if they actually ship) at the end of the Sprint, clogging non-continuous integration and testing systems.
And so on.

Synchronized iterations are said to help with handling dependencies. I think handling dependencies is an organizational skill that doesn't depend on teams being synchronized. Teams that handled dependencies well rarely use synchronized Sprints as a key part of the skill. In fact, always waiting for the end of a Sprint in order to get a dependency resolved can slow things down. Shouldn't the resolution be incorporated immediately, when possible?

I'm looking for stories, for arguments that show synchronized iterations help solve or prevent some problem that makes the negative side effects worth the benefit. Do you have such a story?
5
jason martin's profile photoDavid Koontz's profile photo
3 comments
 
no such story - RE synchronized sprints coordinate dependency reduction; I do however, have stories of non-sync team sprints coordinating dependency reduction & mitigation. I find no correlation to success with coordination and sync iterations.
Add a comment...

Holger Schauer

Discussion  - 
 
Derek Huether makes an interesting analogy between vegetarianism and agile. Maybe this also explains why agile got a lot of push-back as of late, similar to some people declaring that vegetarianism is either an irrelevant fashion while others believe that today you have to live at least vegan.

I guess, Derek's concluding remark for vegetarianism "At the end of the day, to each his or her own" also applies for choosing your approach to development processes.
Agile Training | Agile Coaching | Agile Transformation
2
Edward Wisniowski's profile photo
 
A fantastic post Holger! I agree we do need a principle #13 agree on similarities and not police differences. Great stuff.
Add a comment...

Remy Fannader

Discussion  - 
 
Agile and MBSE can be seen as two major advances in software engineering, more so when they combine to achieve lean phased development processes.
1
Add a comment...

Adam Sobotka

Discussion  - 
 
Very nice reading. I consider myself a beekeeper, do you think that agile solves this issue or is it more general thing?

https://www.netjeff.com/humor/item.cgi?file=DeveloperBees
From: {Windows Sources, March 1995, p. 208} {Contributed by: Mique Talcott} By: Orson Scott Card The environment that nutures creative programmers kills management and marketing types - and vice versa. Programming is the Great Game. It consumes you, body and soul. When you're caught up in it, ...
6
Edward Wisniowski's profile photoSteve Sether's profile photo
4 comments
 
+Edward Wisniowski Exactly, and to me this is precisely the problem we have with insulating developers from the people who use the software.

One of the ways I actually get that satisfaction is talking directly to the people who actually use the software. I had a phone interview yesterday, and asked about that directly. They didn't really have much direct contact between the users and the rest of team. For me that's a pretty big negative because it's much harder to actually get any sense of making a real difference. (Not to mention all the problems of things being "lost in translation".
Add a comment...

Isaac Sacolick

Discussion  - 
 
Using this as a guide when you want to make someone an agile product owner. Will do a follow up post if you comment here and think I missed something. 
Offering advice to organizations trying to cultivate new agile product owners
4
Add a comment...
 
Whatever the opposers of agile say, it's a great way of managing IT projects. This article overviews the main points of criticism against agile and speculates upon how they can be addressed.
There is a lot of criticism against agile software development methodology. Let's review the main points of of this critique and try to bring the truth to light.
5
1
Add a comment...

Sami Linnanvuo

Discussion  - 
 
From command and control mindset to empowerment of teams
One of the biggest changes that a company faces when transitioning to the agile mindset, is the empowerment of the team. For some, it can come as a surprise that there may be less people telling how to do things than previously. There are only as many as the team needs. That’s because the team is self-organising and it will let management know if external resources are needed.
5
3
Mariusz Jurczenko's profile photo
Add a comment...
 
Sometimes you have to pack your bags
I remember vividly a series of conversations with +Alan Dayley about when it was time to leave my firm. I am reflecting on that and the misgivings some people have with their current clients. 
Sometimes you have to pack your bags. Last week I spoke about “struggle” and what I felt it meant. It inspired a strong reaction from a few people. Watching this reaction, it dawned on me, I was witnessing a conversation I ...
3
Peter Bormann (Valonqua)'s profile photoSteve Sether's profile photo
6 comments
 
+Peter Bormann A good way to put it.
Add a comment...