cheap lumigan https://www.rxpillscanadian.com/buy-lumigan-online/

Tag Archives: agile metrics

  • -

Agile Hits the Top 10 on LinkedIn

Tags : 

LinkedIn just released an article on the top career positions based on LinkedIn job posting data in the United States. Leadership roles with Agile and Scrum were in 4 of the top 10 roles. How do you think this relates globally or to the Canadian situation, specifically? If you are a Canadian Agile Leader, pop over to our LinkedIn Group to discuss.

Below are the top Agile roles according to LinkedIn:

5. Product Manager
Median Base Salary: $97,500
Job Openings (YoY Growth): 3,000+ (11%)
Career Advancement Score (out of 10): 8.0
Top Skills: Product Development, Competitive Analysis, Product Launch, Cross-Functional Team Leadership, Marketing Strategy

7. Technical Program Manager
Median Base Salary: $129,000
Job Openings (YoY Growth): 500+ (49%)
Career Advancement Score (out of 10): 8.0
Top Skills: Agile Methodologies, Software Project Management, Software Development Life Cycle, Scrum, Cloud Computing

8. Program Manager
Median Base Salary: $97,400
Job Openings (YoY Growth): 2,300+ (17%)
Career Advancement Score (out of 10): 7.0
Top Skills: Project Management, Project Portfolio Management, Project Delivery, Vendor Management, Business Process Improvement

10. Scrum Master
Median Base Salary: $100,000
Job Openings (YoY Growth): 400+ (104%)
Career Advancement Score (out of 10): 8.0
Top Skills: Agile Methodologies, Software Project Management, Scrum, Requirements Analysis, SQL

Job rankings were based on a weighted score across five areas: salary, career advancement, number of job openings in the U.S., year-over-year growth in job openings, and widespread regional availability. We looked at data from member profiles, job openings and salaries to rank the best jobs for career opportunity. If the scores were tied, we ranked the title with the most open job listings higher.

You’ll find the full LinkedIn report here:
https://blog.linkedin.com/2017/january/20/linkedin-data-reveals-the-most-promising-jobs-of-2017


  • -

How can a CEO make software development teams deliver more features, faster?

Tags : 

I recently provided some free advice on Linkedin about software development. A manager had recently implemented Scrum to improve their development process.

While things are better, the CEO, who doesn’t really care about what methods they use, was not satisfied. He wants more features, faster. In this organization they have a lot of legacy code, so implementing new features is slowed by the complexity of the code base.

The CEO wants a solution that will speed up development. The CEO has proposed taking the best developers from every team and putting them on one team where they will create designs and prototypes of the new features that will be implemented by the teams.

The CEO thinks this approach will speed things up. If we assume the teams in place today are competent, the CEO’s proposed approach could really damage the delivery organization’s effectiveness, morale and really slow things down. I hear this kind of thing regularly, so here is how I think about this problem.

Update: I received feedback from a reader that I should explain why the CEO’s proposal will not work. I skipped this explanation because it will take more time and take away from the point of the article. The situation is similar to a person who doesn’t understand cars trying to fix one. They can spend lots of money replacing car parts and never fix the problem.

Here is my analysis of the risks of the CEO’s proposal. Feel free to skip this specific analysis if you want focus on the solution

In this specific case the solution proposed by the CEO is to take the best developers from the current teams to create a new “super” team. The “super” team’s mandate is to create designs and prototypes for the other teams to implement. So the “super” team won’t actually deliver new features customers can use. Every design decision the “super” team makes now needs to be conveyed to the other teams. This “super team” idea increases communication overhead, slows delivery of new features, takes the most productive developers and stops them from delivering features. The “super team” also breaks the currently functioning teams by removing their best developers, making the teams less productive. The intellectual capacity of the team members is wasted because now they only follow the “super” team’s orders (designs, prototypes, etc). This reduced autonomy reduces intellectual capacity of the organization and decreases morale. The staff on the “super team” are also likely to be frustrated, since they are no longer delivering valuable software features, and the work they enjoy the most will be done by others. The people on the “super team” have little experience working together so they will be slow as they figure out how to work together and become a team. The “super team” will spend most of their time communicating instead of coding. The “super team” will likely suffer from departures as the “best” developers, increasingly frustrated with the lack of programming and increased communication overhead look for other jobs. The CEO thinks his proposal will create a team of heroes that will speed up the process. However the solution actually increases communication overhead, increases length of feedback loops (features working or not), slows down the teams, decreases morale, increases waste and creates frustration. Given the information we have today, that the main problem is a legacy code base that is hard to work with (not staff competency), the “super team” solution does not address the core problem.

The organization has a certain speed at which it can produce new things, and the CEO wants the organization to produce faster. Well, every CEO wants that, so nothing new here. The solution proposed by the CEO will not speed up delivery of features, it will slow down the system. The only way the CEO will get an organization that delivers faster is if he pays very close attention to HOW the company builds products, specifically how work flows starting with a new feature request to completed features in production. One can’t fix a system without first understanding how the system works. By paying attention to how work is done, the CEO and every manager can then lead the organization by asking for regular improvements in the process. There are many thinking tools from Lean, the Theory of Constraints, etc. that can help management and teams find problems and solutions.

Getting features out faster is usually the second thing to worry about. Most software that is built is never used. This has been shown in study after study for more than a decade. The only way the CEO will get more value delivered from the organization is to pay close attention to what is being built and ensuring that only the most valuable and important things are being built. This means really understanding what a customer needs AND what they actually use (vs what they think they want). Lean startup provides lots of practical advice to solve this problem of building the right thing.

Since the biggest fastest improvement is achieved by simply not building crap your customers will rarely or never use, I recommend the CEO and the management team together:

1. Change what you are working on to maximize value

Learn: Watch Agile Product Ownership in a nutshell

Read The Lean Startup by Eric Ries (they will enjoy it, written by a tech executive)

Take a 2 day Certified Scrum Product Owner or Lean Startup course from Robin Dymond Contact Us.

Act: Remove as many features as possible from the product backlog (nice to haves, not needed now, not sure who needs it), and harshly re-prioritize the rest of the features.

For example one management team I worked with used the following prioritization scheme:

    1. 1. We’ll go out of business if we don’t have [Feature]
    1. 2. It will cost us lots of money but we won’t go out of business if we don’t have [Feature]
    1. 3. Everything else
    With this re-prioritization the management team discovered that they could get all the 1 and 50% of the 2 priority features done by the deadline. These priorities cut the delivery time by 50% and ensured that the fraud detection system for a major U.S. bank would not hold up a very large re-platforming program. The rest of the 2 priority features were mitigated with manual processes and delivered after the re-platforming.

Apply and Improve: Implement Lean Startup thinking to product feature discovery, prioritization and product feature validation.

2. Change how you organize work to maximize learning, collaboration, and effectiveness of the organization

Managers and leaders:
Learn: Read and study about Lean, Theory of Constraints (TOC), Scrum Velocity
Take a 2 day Lean and Agile for Managers course on these topics from Robin Dymond Contact Us.
Apply: Value stream mapping and Lean tools, TOC.
Hire a Lean Agile consultant to help management and the organization transition to Agile, Lean and TOC management principles and practices. Innovel consultants specialize in this area. Contact Us.
Improve: Measure your starting baseline, including value stream, bottle necks, information silos and velocity. Incrementally improve the value stream, remove bottlenecks, remove silos, and improve flow.

3. Change how you practice design, coding, and testing to improve quality and speed

Teams:
Learn: Take hands on training in Agile engineering practices and Agile testing.
Apply: Hire a technical consultant to help teams apply Agile engineering and Agile testing practices in their day to day work. Innovel consultants specialize in this area. Contact Us.
Allow time for new practices to be learned and mastered.
Improve: Measure baselines for unit and functional automated test coverage, and code quality. Invest in improving these metrics over time.

Teams working with Legacy code and using Agile face specific challenges. Team members and managers should:
Learn: Read the PDF Working Effectively With Legacy Code and then read the book Working Effectively with Legacy Code
Read about “Technical Debt.”
Apply: Measure baseline technical debt in your system, long term and short term debt. Develop a strategy for paying down technical debt.
Improve: Implement the technical debt strategy together with teams and management and actively manage technical debt.

Metaphor for management: “Does shoving more paper into a printer make it print faster or make things worse?”

smoking printer

Happy New Year!!


  • -

Does your Scrum team pass the Scrum test used at Nokia? Try it.

Tags : 

A basic pass / fail test was developed at Nokia to understand if the many teams were implementing Scrum correctly. You can take this test by clicking on the link below.

I will aggregate the results and email them to you if you are interested. I will present the results back to the Agile/Scrum community for discussion once we have 1000 responses.

As of January 26, 2009 we have 208 responses.

Please forward this email to other teams so we can get as many responses as possible.

The test:
http://spreadsheets.google.com/viewform?key=p_DGqV8jkE4Wmpir24Xt8Zg

cheers,
Robin Dymond.


  • 1

Earned Value Measurement – the useless metric for Agile

Tags : 

Earned Value Measurement, for those unfamiliar, is a misnamed metric that is common in more sophisticated waterfall or phased project management. It actually has nothing to do with anything earned. EVM is a measure of how close you are to some pre-defined schedule and pre-defined budget. In essence it is a tracking metric, that when you are 100% on schedule and on budget, you “meet” the standard. Any deviation and you drop below the standard.

In Agile, we start from the assumption that we cannot predict the future. While we know generally how much time scope and budget we have, we know that it is waste to spend large amounts of time and resources building predictive plans. We always flex on scope, and we inspect and adapt to the learning of the team, customer, and business environment. Agile methods can adapt because of the delivery of working product into production, early, often, and throughout the project. This has many virtues – it allows real customer feedback, it validates or invalidates business/investment decisions, it shows strengths and weaknesses of approach, and it provides real learning opportunities for the team, customer and business. Waterfall methods steer like a dragster, and EVM was a tool to tell you how far you had deviated from the initial direction you pointed the vehicle. Agile methods are like driving a car, you look out the window and adjust your course accordingly. If you were to drive from NY to Florida, would you plan every turn before you leave, and how long you would take? Would a tool like EVM, knowing how “off” you were from your initial plan be useful to your trip? Wait! We can’t stop for coffee, our trip EVM meter will show we are deviating from our plan!

Agile methods deliver product to the business and a return on investment early, often, and throughout the project. This means that it is now possible to measure ACTUAL market acceptance and ACTUAL ROI. We are not building bridges or roads where the capital cost outlay is amortized over 20 years. Using EVM does not add value to the project, and does not increase understanding or visibility. Agile and Lean methods emphasize regular demonstrations of actual progress, and regular releases into production. This is what managers need to look at. EVM is built on estimates that are wildly inaccurate because of the uncertainty built into any complex endeavor where the customer doesn’t know what they want until they go on a learning journey with the team, and the business context is continually changing. I urge everyone in the traditional EVM community to just drop EVM, and focus on how you can help customer measure actual, real business value with every release. This is where new ideas for measuring rapid market feedback, capabilities delivered, and how these can drive learning in the organization. I would also ask that EVM practitioners learn something new, and stop trying to shoehorn irrelevant yet burdensome ideas into a completely new way of working.

For more detailed thoughts on what to measure in Agile, I would invite you to read a paper published by Deborah Hartmann and myself at Agile 2006 on Agile Metrics and Diagnostics, you can find it in our Articles section.


where can i get seroquel https://www.canadapharmrxon.com/buy-seroquel-online/