I liked the Scrum framework. Once I found The Scrum Guide and digested it, I saw the beauty of the design and intent. I've spent a lot of time and energy attempting to correct misconceptions and spread information of its benefits. However I continue to see traditional, command-and-control, top-down, hierarchical, micromanagement everywhere: blogs, comments, articles, conversations, etc.
The more I call out ignorance the more I see in replies and likes. Certified Scrum Masters (or ScrumMaster as they say) from Scrum Alliance were known issues. I see it also comes from industry "experts" such as Mike Cohn. Professional Scrum Trainers are also problematic.
I think I am done with this battle. The agile philosophy has had over 20 years to become the norm. People would rather remain in the comfort of repeating failure than actually learn a new way.
Showing posts with label technology. Show all posts
Showing posts with label technology. Show all posts
Saturday, November 18, 2017
Wednesday, November 8, 2017
Scrum Guide Revisions 2017
The Scrum Guide revisions November 2017
- Highlighting that the framework can be applied beyond software is a nice addition.
- The additional information and rewording for the Scrum Master role will be helpful to some.
- Daily Scrum changes are a great step in a positive direction. Promoting a conversation over the three question format (3QF) or walking the board has been a challenging sell to many.
- The need to further reiterate the definition of a time-box highlights one of many symptoms exemplifying that Scrum, for many, is not "Simple to understand" as advertised. :-)
- The requirement to have "at least one high priority process improvement identified in the previous Retrospective meeting" on the Sprint Backlog creates some issues as it does not align with the definition of the Sprint Backlog.
- It is not a Product Backlog Item (PBI).
- It is not a part of the plan for delivering the Increment and realizing the Sprint Goal.
- It is not a forecast of functionality.
- The Sprint Backlog belongs solely to the Development Team therefore so does this process improvement item.
- Changes are inspected and adapted during the Daily Scrum (for Development Team only).
- Development Team works through the plan.
- Only the Development Team can change its Sprint Backlog during a Sprint.
- It is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint.
Saturday, October 7, 2017
Some Software Development History
There is a lot to the history of software development. Start with Managing the Development of Large Software Systems[1] (1970), the misunderstanding that led to the waterfall process and classic project management[2]. The term agile comes from the Manifesto for Agile Software Development[3] (2001) though the groundwork for that philosophy started in the 1990s (history[4])
including eXtreme Programming[5] and Scrum[6]. Scrum being based on[7] Toyota's manufacturing model where Kanban and its principles[8] began: The New New Product Development Game[9].
[1] https://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
[2] https://www.pmi.org/about/learn-about-pmi/what-is-project-management
[3] http://agilemanifesto.org/
[4] http://agilemanifesto.org/history.html
[5] http://www.extremeprogramming.org/
[6] https://www.scrum.org/
[7] https://www.scruminc.com/takeuchi-and-nonaka-roots-of-scrum/
[8] https://en.wikipedia.org/wiki/Kanban#Toyota.27s_Six_Rules
[9] https://hbr.org/1986/01/the-new-new-product-development-game
including eXtreme Programming[5] and Scrum[6]. Scrum being based on[7] Toyota's manufacturing model where Kanban and its principles[8] began: The New New Product Development Game[9].
[1] https://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
[2] https://www.pmi.org/about/learn-about-pmi/what-is-project-management
[3] http://agilemanifesto.org/
[4] http://agilemanifesto.org/history.html
[5] http://www.extremeprogramming.org/
[6] https://www.scrum.org/
[7] https://www.scruminc.com/takeuchi-and-nonaka-roots-of-scrum/
[8] https://en.wikipedia.org/wiki/Kanban#Toyota.27s_Six_Rules
[9] https://hbr.org/1986/01/the-new-new-product-development-game
Tuesday, May 16, 2017
Corporate Bureaucratic Agile
Glen B Alleman gives plenty of examples of the corporate bureaucratic idea of what agile is. There is nothing wrong with attempting to identify risks and putting measures in place to reduce risks. There is a problem with attempting to predict the future. There is nothing in his content which reflects the values and principles of the manifesto. Long term planning based on estimates of unknowns.
https://twitter.com/galleman/status/864330448477999105
https://twitter.com/galleman/status/864300464619180033
https://twitter.com/galleman/status/861233980686745600
For a guy with 3K+ followers . . . he doesn't receive a lot of interactivity . . . except when he is exemplifying his closed-mindedness with others.
https://twitter.com/galleman/status/864330448477999105
https://twitter.com/galleman/status/864300464619180033
https://twitter.com/galleman/status/861233980686745600
For a guy with 3K+ followers . . . he doesn't receive a lot of interactivity . . . except when he is exemplifying his closed-mindedness with others.
Partial Features of .NET Core in Visual Studio 2017
There are some great things coming in Visual Studio 2017 . . . someday. Some features have existed since 2013. Some only partially. With .NET Core being the future, these features need to be completed, especially since much of it mimics a nodeJS-esque process.
Live testing. It looks as though it is working, the progress visual moves, but the tests aren't actually being executed; this is the most misleading UI/UX in a long time. Some articles, and GitHub issue notes say "next release" but we're still waiting and wanting.
Browser Explorer. Technically it works. The lack of live reload is heartbreaking. Gulp (which Microsoft recommends) and Grunt can watch for filesystem changes and execute tasks, such as browser refresh with connect, yet this IDE hasn't implemented it.
There are plenty of good reasons to switch. Being on 15.3 without these features, and with many open issues, is a let down. Here's to hoping that Microsoft can clean this up . . . and soon.
Live testing. It looks as though it is working, the progress visual moves, but the tests aren't actually being executed; this is the most misleading UI/UX in a long time. Some articles, and GitHub issue notes say "next release" but we're still waiting and wanting.
Browser Explorer. Technically it works. The lack of live reload is heartbreaking. Gulp (which Microsoft recommends) and Grunt can watch for filesystem changes and execute tasks, such as browser refresh with connect, yet this IDE hasn't implemented it.
There are plenty of good reasons to switch. Being on 15.3 without these features, and with many open issues, is a let down. Here's to hoping that Microsoft can clean this up . . . and soon.
Wednesday, September 30, 2015
Just Another ScrumBut
Scrum is the desired methodology at TR. I've heard about and read about Agile before, so I was interested to learn more about it. Beginning a new product platform seemed like a great time to also institute a new software development methodology. Here is a retrospective on where we are today.
The first corporate impediment was lack of planning. Our onsite training was scheduled without regard for the Development Operations team's schedule. Therefore they rushed to create and configure our TFS instance. This led to users not being able to connect, missing users, users who should not have been users, workflow issues, and a poorly constructed source tree.
We did not have a dedicated Product Owner or Scrum Master. (At the time I didn't know what those were.) So we used a new to the company (and industry) Development Manager as the Scrum Master and a tenured Development Manager as the Product Owner. Later we learned why this was bad.
The corporate Agile Trainer came to our site and our week long endeavor began. Wanting to fully understand the Scrum framework, I asked a lot of questions and challenged a lot of the statements. There was no mention of The Scrum Guide. Some of the material taught was about two years outdated. Misrepresentations and falsities were also presented. The last two days of training, without being expressed prior, became the beginning of our first Sprint. So with many new developers, unfamiliar with our product and new platform vision, we created the foundation of a Product Backlog and sized those stories.
Having been trained we were immediately expected to produce a Minimum Viable Product. Lacking proper preparation or even a Planning Meeting, we began to create a mess (as in not clean) of code. We "successfully" completed the Sprint and were on to the next Sprint.
During the second Sprint we started to receive requests and concerns from management regarding productivity of employees. You know, the classic 100% utilization ignorance. Being the tenured developer, having experience protecting troops, and not being a "yes man" to management, I fielded those conversations to allow the Development Team to focus on producing a quality product. I used what little knowledge I had gained from the training and a decent amount I had been learning from independent research to keep management at bay.
During Sprint 3, we began to recognize the issues with have a direct manager as the Scrum Master. He was trying his best, but Scrum Master is a role that should not and can not be conducted using classic management skills. We discussed it as a Team and requested that we use one of our Team members as a Scrum Master starting the next Sprint.
Once we began Sprint 4, things improved. The members of the Development Team were becoming familiar with each other, the processes were improving, there was less concern about Scrum Master role conflict. By the end of Sprint 5 almost everyone was seeing the benefits to the Scrum framework, especially how it could improve our ability to create and deliver quality software. I discovered The Scrum Guide and began implementing some of the missing pieces.
Of course things weren't clear sailing. We had Team members who had to split commitments between projects. We hired some more resources including a Product Owner, who was actually a classically PMI trained Project Manager. Yet another failure from the "agile" mentors above. Management wanted us to track multiple projects in the same Product and Sprint backlogs. They began asking about individual productivity again. I quoted The Scrum Guide and the wolves were at bay once again.
At the start of Sprint 7 I believed that at thirteen people, we needed to split into at least two smaller (Scrum recommended) sized Teams with resources dedicated to only one product. A few senior members discussed it and we introduced the topic to management. They agreed that it was a good idea. Our Product Owner suggested that we continue to drive the initiative by drafting a proposal to present to management. Why hadn't the so-called Agile Coach seen this and made preparations or initiated the conversation? Why did we need management approval to be self-organizing?
The proposal was drafted, edited, and approved by the "small council" and sent to the Agile Coach for comment. He gave some feedback and was also happy that we were discussing splitting into multiple teams. The proposal was sent to management. Later I realized that this was the trainer's first interaction with the Development Team since training. Being a group new to Scrum and lacking trained or experienced people to fill the Scrum Master and Product Owner roles, we were not offered additional coaching or assistance.
About this time the requests began again to have every Development Team member have his/her name on a task at all times. I expressed the same concerns that we had before, I quoted The Scrum Guide, I asked for reasoning as to why this was important, I expressed the Team's concerns about micromanagement. The was a lot of illogical or irrelevant "reasons" and "we're not using this for evaluation" talk. There were even a few Scrum incorrect statements made by the Agile Coach.
In the end, during Sprint 8, the violating directive was given and we have been attempting to comply. Our Sprint Backlog quickly became a cluttered mess. We were wasting time creating and updating unnecessary tasks. Management even sent an email asking why not all members didn't have an In Progress task. I have submitted a direct query to the Agile Coach as to how this is not a direct violation of The Scrum Guide.
What happened to the proposal? It was still being considered. Some managers could/would not resource plan, didn't seem to accept the single product focus objective, and wouldn't commit to staffing. We are requesting feedback and approval again.
Management has failed. They have failed to adapt to the Agile philosophy, especially the Scrum framework. They have failed to be the ones foreseeing and addressing challenges. They have failed to coach and empower. This is why, unless things change, TR will be another failed Agile implementation and be just another ScrumBut.
The first corporate impediment was lack of planning. Our onsite training was scheduled without regard for the Development Operations team's schedule. Therefore they rushed to create and configure our TFS instance. This led to users not being able to connect, missing users, users who should not have been users, workflow issues, and a poorly constructed source tree.
We did not have a dedicated Product Owner or Scrum Master. (At the time I didn't know what those were.) So we used a new to the company (and industry) Development Manager as the Scrum Master and a tenured Development Manager as the Product Owner. Later we learned why this was bad.
The corporate Agile Trainer came to our site and our week long endeavor began. Wanting to fully understand the Scrum framework, I asked a lot of questions and challenged a lot of the statements. There was no mention of The Scrum Guide. Some of the material taught was about two years outdated. Misrepresentations and falsities were also presented. The last two days of training, without being expressed prior, became the beginning of our first Sprint. So with many new developers, unfamiliar with our product and new platform vision, we created the foundation of a Product Backlog and sized those stories.
Having been trained we were immediately expected to produce a Minimum Viable Product. Lacking proper preparation or even a Planning Meeting, we began to create a mess (as in not clean) of code. We "successfully" completed the Sprint and were on to the next Sprint.
During the second Sprint we started to receive requests and concerns from management regarding productivity of employees. You know, the classic 100% utilization ignorance. Being the tenured developer, having experience protecting troops, and not being a "yes man" to management, I fielded those conversations to allow the Development Team to focus on producing a quality product. I used what little knowledge I had gained from the training and a decent amount I had been learning from independent research to keep management at bay.
During Sprint 3, we began to recognize the issues with have a direct manager as the Scrum Master. He was trying his best, but Scrum Master is a role that should not and can not be conducted using classic management skills. We discussed it as a Team and requested that we use one of our Team members as a Scrum Master starting the next Sprint.
Once we began Sprint 4, things improved. The members of the Development Team were becoming familiar with each other, the processes were improving, there was less concern about Scrum Master role conflict. By the end of Sprint 5 almost everyone was seeing the benefits to the Scrum framework, especially how it could improve our ability to create and deliver quality software. I discovered The Scrum Guide and began implementing some of the missing pieces.
Of course things weren't clear sailing. We had Team members who had to split commitments between projects. We hired some more resources including a Product Owner, who was actually a classically PMI trained Project Manager. Yet another failure from the "agile" mentors above. Management wanted us to track multiple projects in the same Product and Sprint backlogs. They began asking about individual productivity again. I quoted The Scrum Guide and the wolves were at bay once again.
At the start of Sprint 7 I believed that at thirteen people, we needed to split into at least two smaller (Scrum recommended) sized Teams with resources dedicated to only one product. A few senior members discussed it and we introduced the topic to management. They agreed that it was a good idea. Our Product Owner suggested that we continue to drive the initiative by drafting a proposal to present to management. Why hadn't the so-called Agile Coach seen this and made preparations or initiated the conversation? Why did we need management approval to be self-organizing?
The proposal was drafted, edited, and approved by the "small council" and sent to the Agile Coach for comment. He gave some feedback and was also happy that we were discussing splitting into multiple teams. The proposal was sent to management. Later I realized that this was the trainer's first interaction with the Development Team since training. Being a group new to Scrum and lacking trained or experienced people to fill the Scrum Master and Product Owner roles, we were not offered additional coaching or assistance.
About this time the requests began again to have every Development Team member have his/her name on a task at all times. I expressed the same concerns that we had before, I quoted The Scrum Guide, I asked for reasoning as to why this was important, I expressed the Team's concerns about micromanagement. The was a lot of illogical or irrelevant "reasons" and "we're not using this for evaluation" talk. There were even a few Scrum incorrect statements made by the Agile Coach.
In the end, during Sprint 8, the violating directive was given and we have been attempting to comply. Our Sprint Backlog quickly became a cluttered mess. We were wasting time creating and updating unnecessary tasks. Management even sent an email asking why not all members didn't have an In Progress task. I have submitted a direct query to the Agile Coach as to how this is not a direct violation of The Scrum Guide.
What happened to the proposal? It was still being considered. Some managers could/would not resource plan, didn't seem to accept the single product focus objective, and wouldn't commit to staffing. We are requesting feedback and approval again.
Management has failed. They have failed to adapt to the Agile philosophy, especially the Scrum framework. They have failed to be the ones foreseeing and addressing challenges. They have failed to coach and empower. This is why, unless things change, TR will be another failed Agile implementation and be just another ScrumBut.
- Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
- Development Teams are structured and empowered by the organization to organize and manage their own work.
- The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team
Subscribe to:
Posts (Atom)
