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
Showing posts with label work. Show all posts
Showing posts with label work. Show all posts
Saturday, October 7, 2017
Tuesday, May 16, 2017
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
Tuesday, August 5, 2014
Making the Work PC Less Annoying
Screen Saver
Who doesn't love the corporate marketing screen saver that you can't change because of the GPO? That's it . . . ALMOST EVERYONE!!
My first approach was a just-live-with-it mentality. Well, not really. I just changed the power saving to turn off the monitor before the screen saver activated. It makes total sense that we can change that but not the screen saver itself. *sigh*
Next was to attempt to update the registry. Of course that kept being overwritten, so I quickly relinquished that idea.
The final step was very straight-forward. I created a copy of the actual screen saver file. Then I created a copy of the photo screen saver file and renamed it. So now everything looks good to the configuration, yet I have the screen saver I want. HINT: You can adjust a screen savers settings by right-clicking the ".scr" file.
Virus Scan
Common sense settings:
- Run during the workday
- Permit 100% CPU usage
- Do not allow settings to be changed
- Protect the registry settings
- Allow the user to manually delay execution
Initial attempt was to update the scan time via the registry shortly before the scan was to execute, then again shortly before I wanted the process to begin. The scan did not take place. There must be a timing issue.
So I ran Process Monitor to watch the registry. I manually delayed the schedule via the UI and captured the changes. Once that was in-hand a simple scheduled task executing a batch file to update the registry did the trick.
ENJOY!!
Monday, August 6, 2012
Important(?) Meeting
There's a project which has been on-and-off the radar for about three years. I've finished up the final work and it's time to discuss deployment. A meeting is scheduled for Thursday. Then it is moved to Monday. After a late start Monday morning, I walk in to the comment, "I'm glad I rescheduled that meeting." I reboot my hanging machine to see the rescheduled invitation . . . Wednesday of the following week. How important is this deployment?
Subscribe to:
Posts (Atom)
