Justin York – Simdesk

“Del's leadership was instrumental in bringing agile methodologies to our development team. While transitioning to scrum, I often consulted with Del about how to handle things in the scrum framework. Once our team was fully running on scrum, I felt that we were at least twice as productive as we had been in the past.”

Matt Willson – Pervasive Software

“As Delmar's manager for over a year, I was very impressed with the simplicity of his designs, the quality of his software, and the tenacity he brought to problem solving, especially customer issues. Delmar provided strong leadership for the developers who worked under his tutelage.”

Steve Mook – Pervasive Software and Simdesk

"Del is experienced,enthusiastic and tenacious - an excellent team lead with expertise in UI design and development and Scrum project management. He is willing to learn new technologies, challenge assumptions, take risks, and be accountable for results. His skill and leadership would benefit any team that seeks to improve its ability to deliver value to customers and to the business."

My Agile Experience

What was really exciting was to see the Scrum methodology adopted company wide at Simdesk. Because of the success of our team I was able to train and mentor other team leads, managers and corporate executives to use Scrum. This lead to increased productivity and better communication among the teams, support, product managers and upper management. Goals are well defined and consistently meet.

Tags

adoption architecture books build change collaboration deploy design integratoin learning management performing productivity quality release safety sprint team Team Member team safety training user stories

My Reading List

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn)) by Lyssa Adkins (Paperback - June 14, 2010)

Available on safaribooksonline.com as a Rough Cut.

Succeeding with Agile: Software Development Using Scrum [Book] by Mike Cohn - Addison Wesley

The Dip: A Little Book That Teaches You When to Quit (and When to Stick) by Seth Godin

Fierce Conversations: Achieving Success at Work and in Life One Conversation at a Time by Susan Scott

Collaboration Explained: Facilitation Skills for Software Project Leaders - Paperback (Jan. 16, 2006) by Jean Tabaka

Agile Product Management with Scrum: Creating Products that Customers Love (Addison-Wesley Signature Series) Roman Pichler

Practices of an Agile Developer by Venkat Subramaniam and Andy Hunt - Pragmatic Book Shelf

Archive for integratoin

Sep
23

Quality and the process

Posted by: Delmar Hager | Comments Comments Off

Quality of software or any product that we sell and provide a customer seems to be talked about but not effectively addressed in most software processes. In the process of reducing the size of my technical library I have been looking at some of my “old” books. It is interesting to see how many of these books are referenced in new books that are published.

The book “Improving Software Quality: An Insider’s Guide to TQM” by Lowell Arthur (1993)  is one I was just perusing. In the preface he has a section on eliminating the testing group. Wow, this is a book on Total Quality Management and they made a bold statement such as this. Tell me how many companies have eliminated their testing groups to improve quality?

Here are some other quotes from the preface:

Create a constancy of purpose toward quality and continuous improvement

This is a underlying principle in Agile development. The whole team is involved in process improvement through constant inspection.

Institute leadership instead of management by numbers

That is the goal of self-organizing teams. Leadership is distributed among the team members in that they agree to common goals for quality and hold each other accountable. Just having a list of defects and managing this list is not a sign of a quality organization.

Drive out fear so that everyone may work effectively.

Time and time again I hear the complaint that a person is evaluated by the number of defects that are found in their code. This creates an environment where people want to cover up any problems they discover. I just recently had to defend the number of defects that were recorded against our team during a clean up sprint (these were actually new requirements). I want any defect to be recorded so we do not have them reach the customer. Removing the fear of recording defects goes a long way to creating an quality product.

Break down barriers between departments and work groups

Simply stated, have cross function teams. If everyone is on the same team you have no barriers.

Eliminate slogans, work quotas and management by numbers. Substitute leadership.

What would our managers do? I guess I am being a little sarcastic. But so many activities our managers do do not enhance quality.

Remove barriers that rob workers (management, professional and craft) of pride of workmanship.

Nothing encourages a team more then a job well done that exceeds customer expectations. We want to be proud of our work.

Nothing new is under sun as wise King Solomon said. Agile development provided solutions that provide for a quality product.

Categories : Agile
Comments Comments Off
Aug
24

Software Delivery – Continuous Itegration, Build and Deploy

Posted by: Delmar Hager | Comments Comments Off

Years ago I worked for a start-up company and under a very demanding manager. He was a stickler about not having build breaks and that our software could be delivered to whom ever we want after a build. The first task he would do on a new project was to create the make file that would build the install script for the product. To him that was the most critical component and must  be constantly maintained during the development cycle. After every build of the product we had an install package.

Software delivery is so critical especially with very complex projects that involve multiple teams. Deploying software into a SOA that is 24×7 presents challenges that we never faced in our small start-up. But the principle remains the same, “You need to know how to deliver your product right from the beginning of the project”.

How many project put this as a top priority? I have seen many situations where how we  deliver  product into the “live” environment is not considered until the end of the project. Why should this be important?

  1. Large systems can be fragile
    With a small product you can control the environment it will be deployed into. With large system deploys their are many factors you have to be aware of during a deploy. Just one table not being updated in a database can cause serious problems during a deploy. With the multiple connections that are involved it can be very difficult to track down the problem.
  2. The individual teams cannot understand the whole
    It is unrealistic to have all of the teams on the project understand every aspect of the deployment. The team’s focus is on their functionality they need to provide.
  3. A continuous integration,  build and deploy process needs to be implemented
    Continuous integration, build and deploy are the cornerstone on which a solid software system can be built. Without this in place you will have difficulty deploying a workable solution.
  4. A integration and build team is critical
    This is the team that is responsible for building and deploying the product. They understand all of the components of the system and determines the deployment strategy.

A good Agile process depends on having the foundation in place. Continuous integration, build and deploy is the foundation for good process.

Categories : General
Comments Comments Off