Welcome to the discussion about this lecture. Here you can ask questions or post feedback about this specific lecture.
2 Likes
Hello Ivan,
I found the agile section very interesting but in my opinion you missed an opportunity here.
For me agile is not an unknown concept so when you talked about āblurred rolesā it got my serious attention because I see this in my real life also as a problem. If communication comes from all directions to de developers (front end or backend) they get an information overload and we need a leader indeed.
But how will we put that leader inside that concept without ruining the concept itself and without ending in chaos.
Can you explain what your vision is to solve that problem ? Where would you put that leader en how would that affect communication ?
thnx, keep up the good work, I really love the videos
I little bit of feedback here. You started the video with the words that youāre gone talk about Agileā¦but you never explained what is Agile all about. Is it a concept, is it a software, is it a method?
Itās far more easier for the student if this basics to be explained in the very beginning rather then not at all.
1 Like
Hi. Maybe this is off topic but Iām gonna ask anyway. I have a question about leadership. Letās say you are in a team and the leader in the team is not so good at being a leader. What is the best solution for it? Thanks for any answer.
1 Like
Hi. That does not sound like an Ideal situation too be inā¦
My experiance is to try to do my best for the business, but it depends on the leader, the business, and the hole situation around the problems you have with the leader. Why is he not a good leader? Is it only you who think this, If management thinks he does a good job, I have one advise. Start applying for work somewhere else, because itās usually not worth the hassle to try to change the situation.
Thatās what i think, but again, your answer is very general and hard to give a presise answer to you.
Good luck.
Ivo
1 Like
Hey you make a good point there. I guess it adds up more to the situation and everything around it. Thanks for your answer.
1 Like
@Timmy I have been in the same situation a few times. It was daunting at first for me, then I changed my approach. Remembering āThe Peter Principleā, I began the approach of āthis person will fail, so, how do I help them fail gracefully with less damageā. That may be a rather harsh way to approach the situation, but someone who is leading usually knows when they are failing. Step one was to keep my game on point. Step two is to help my immediate team members succeed if my game is good. Step three is to never badmouth anyone. That last one can be the toughest if you have gossipers on your team, so, avoid situations where others can gossip. I did that by keeping some distance from others. The results consistently were; my work was impeccable, the leader gave me good references, teammates remember me when positions open. I hope this helps you!
3 Likes
Thanks Michael for the response!
Its sounds really interesting and make me think of different situations. I never heard of the Peter Principle so thanks for that I will take a closer look into that principle.
2 Likes
Definitely do! I encourage people every chance I can who are in any supervisory, managerial, or executive position. The short version of it is; we get promoted for two reasons- success or longevity- however, we are promoted until we reach a position that we cannot do. I would go deeper, but, Iād like for you to take a long look at it.
3 Likes
This is a very interesting lesson. IMHO when we adopt these hints there are a couple of issues that should be fixed. As said an agile communication can take to blurred roles. Working properly in a team is good but as said some kind of leader is needed. So the issue is how to have an agile communication without breaking the roles and the leadership?
The second issue is in the use of MVP. Obviously customer is the king, but very often customers (even the open-minded to technology) are very conservative. So we have to fight against ourselves since we would believe in a completely different project, but money coming from conservative customer dictate a completely different line.
2 Likes
Hi @ivan In my opion you are too negative about other ways of running projects than Agile (for example waterfall projects). Agile is for sure not the silver bullet for Every project (lots of articles about this and also my personal experience). I am running many SAP programs >3 million euro for large multinational companyās they are coming back on Agile and product teams. You canāt have all required skills in your team when you are doing programs in a large organization. Agile teams are really focused on their own backlog and not how it interacts with other (Agile teams)
My conclusion first think carefully what fits best in every project to use as implementation methodology (or do certain parts Agile and others whaterfall). Agile fits most of the times best in development projects.
1 Like
This is a very useful video on AGILE and how the structure works when building a project.
1 Like
Thank you, this has largely explained to me why nothing works properly and the whole world has become one enormous frustration engine where the customer has become an employee who pays the company to do work for it, and there is definitely no concept of SERVICE or SERVICE ATTITUDE any more. Future shock has already happened, and the weak are being pushed to the margins and right off the edge. Hierarchy works for me. Actually, I think we need to learn how to do things more slowly and considerately, thinking about the effects of our products in the wider sense. Even the simplest things that were easy for people who know how to do things with physical tools in the real world have had unnecessary layers of complexity added to them. Question: have any of you lot ever kept a fire alight for a whole winter? That is my rant for today. The real world and nature are also VERY interesting.
1 Like
Iāve been working as an Agile coach in the past 5-6 years, helping organisations to be more nimble and deliver value early and continuously to their customers.
While a lot of people are getting stuck with basic practices, I like how @ivan focuses on customers (even developers, which is rare unfortunately), delivering value as early as possible, collecting feedback and adapt to change. Well done 
.
1 Like
Thank you for opening this topic. Iāve had experience with Agile now for over 10 years and personally I think it has become a dung hole for organizations. It has created so many unnecessary job roles in the form of a āscrum masterā who is supposed to keep up with progress of sprints. Now, there are terminologies like Epics, Stories, Sprints and whole slew of made up names that are confusing to people whoāve never worked with Agile before. My opinion on agile is that it is a revenge adapted by ignorant management as a revenge for years of having to listen to technobabble by engineers. For example:
I was given an assignment to integrate IBMās discovery for Mainframe known as TADz. Tivoli Automated Discovery. The project began as Ivan describes it. We talked to the MF team to see what they would be comfortable using. I started to code the data integration that connected Pentaho to DB2 with a JDBC driver and got the POC done within about a week. Then I created a data model in the CMDB that could be used for Asset, Incident and Change management. The prototype was done in about 3 weeks. At that point I kept communicating with the director of the MF team to show what the end result will look like. During this time I joined roughly 3 scrum meetings each week. No-one in that meeting understood what I was actually talking about in technical terms. In my opinion it was a waste of my time to even attend. However, for each āSprintā I have documented what I did as the weeks progressed. Eventually my solution got put into production and its life cycle as a product began for the company. It became very popular and easy to use because Iāve really thought it through and having Agile tracking on hand allowed me to predict short falls.
Next came updates. Details on what needed an update is not important, but what is important is that I was able to go back to Agile and track my notes on how I did the integration. I was also able to document my bottlenecks and demonstrate what eventually would become a maintenance component. Something I was putting weight on during the sprints that was declared as low in priority at the time, but became much more important as the product was used in production. I was able to ābringā the management team back to the date when I had made that projection and was told it was not important. I gained credibility at that point by having that vision. Although I have to say that for me, the coder, it was not hard to make that prediction. It was obvious, as Ivan points out, that ātimeā and competition are the enemies of quality. Agile can produce results āIFā used properly by management, but so far Iāve not seen good evidence that the scrum masters know the difference between a hole in the ground and their behind (where the Sun donāt shine as they say in Texas).
Thx for reading.
1 Like
Hi all,
Just wanted to chip in a few extra thoughts when it comes to project management.
Although I do generally agree with what is detailed in the lecture, there will be some other factors that feed into the how the project is managed., which I believe are importantā¦Ultimately the trade off between Budget, Time and Scope.
Most projects will have these 3 constraints:
-
Though difficult I believe it is important to get as complete a set of requirements from the customer as possible, though I understand this can be difficult and potentially not feasible as ideas will also materialise as the project progresses, however have a clear set of requirements will also allow you to pull together an accurate costings for the project and time frame.
-
Following on from this, agree that consistent āworkshopsā with the customer are important, to verify that the development is heading in the right direction, however these also have to be managed and scope creep minimised.
As new functionality/requirements may impact the cost or time elements of the project.
Some functionality can be categorised as āmust haveā and ānice to haveā, and then a potentially put into a phase 2 project.
- Also, the importance of a defined set of requirements may arise at the end of a project, whereby you may need to show that a project has been delivered by ticking off the functionality checklist.
ā¦bit of a brain dump, hopefully makes sense and is useful.
2 Likes